Remove/deprecate/simplify the ms element

I've been googling for some time this morning, looking for some example of <ms> use that is somehow not just effectively <math><ms>hello world</ms></math>. For most elements I've looked up, I can find some reasonably simple examples of something that is recognizable as "mathy" content and helps me understand what it does, and what it is for. But, for <ms>, I can't.

Can someone please provide an example demonstrating a real (simple, hopefully) use of this element and why it is useful/necessary to have this particular distinction? If not, can we just drop it from core?

it essentially displays the same as mtext, but defaulting to a monospace font and surrounded by quotes. so it could in theory be dropped from core but it is a useful distinction especially when using math layout for computer code rather than "pure math" to maintain a distinction between strings which are values and text which is part of the surrounding sentence structure so <math><mi>str1</mi><mo>=</mo><ms>foo</ms> <mtext>  or  </mtext> <mi>str1</mi><mo>=</mo><ms>bar</ms></math> so the ms foo and bar are values in the expression but <mtext> is just part of the sentence inlined into the display for layout reasons. the justification is actually very similar to that of <mn> which also displays pretty much as mtext, but numeric values, like string values often have a special role.

…

On Wed, 17 Jul 2019 at 14:57, Brian Kardell ***@***.***> wrote: I've been googling for some time this morning, looking for some example of <ms> use that is somehow not just effectively <math><ms>hello world</ms></math>. For most elements I've looked up, I can find some reasonably simple examples of something that is recognizable as "mathy" content and helps me understand what it does, and what it is for. But, for <ms>, I can't. Can someone please provide an example demonstrating a real (simple, hopefully) use of this element and why it is useful/necessary to have this particular distinction? If not, can we just drop it from core? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#120>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJVYAWFP2X7RJO7524DH5LP74QMDANCNFSM4IEQVNMA> .

Thanks David. I'm wondering still though: can you provide an example demonstrating an actual/real (simple, hopefully) use of this element? In other words, not a thing that is showing what it does with foos and bars, but - some actual math content that helps me (or someone else) understand how it serves an actually useful purpose?

here at work we generate a lot of code from mathml and <ms>123</ms><mo>=</mo><ms>123.0</ms> is string comparison and false, and <mn>123><mo>=</mo><mn>123.0</mn> is numeric comparison and probably true, if you didn't have <ms>123</ms> you would presumably use <mtext>"123"</mtext> which displays the same but is harder to use for code generation as it mixes the actual string value of 123 with the string literal syntax, so for example you'd have to work harder for it to be equal to <mtext>'123'</mtext> or <mtext>"123'</mtext> to be an error. One could argue that core is only focussed on presentation in a browser in which case ms and mn are both pretty much replaceable by mtext, but there are many benefits to having the math in the browser page also be processable as math, and distinguishing numeric and string literals is a more or less universal feature of any programming language that you want to use to process the expressions.

…

On Wed, 31 Jul 2019 at 14:53, Brian Kardell ***@***.***> wrote: Thanks David. I'm wondering still though: can you provide an example demonstrating an actual/real (simple, hopefully) use of this element? In other words, not a thing that is showing what it does with foos and bars, but - some actual math content that helps me (or someone else) understand how it serves an actually useful purpose? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#120>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJVYAWCYFKKW7OKYVG7ZPDQCGKN7ANCNFSM4IEQVNMA> .

@emilio

cc @emilio @rwlbuis

Some arguments against ms:

It is only implemented in Gecko, not in WebKit. I'm still really skeptical we should upstream our support to Chromium given the points described here, which make the justification weak for an intent-to-implement.
It is not used a lot in complex math formulas? At least not as string literals? I wonder how many MathML formulae actually use ms and how often authoring tools generate it.
The CSS implementation is broken in RTL mode:
CSS implementation of <ms> does not work in RTL mode #126
In general generating text that is not in the DOM is bad for native implementation (need to create anonymous layout nodes, need special handling in the a11y tree etc). This is similar to issues explained for removing mfenced (Removal/Deprecation of <mfenced> #2). More specifically here:

There is already a precedent, see this Mozilla security bug (now public) that led to the CSS implementation above: https://bugzilla.mozilla.org/show_bug.cgi?id=476547
The CSS implementation relies on :before { content: ... } and :after { content: ... } which are known to be a pain for accessibility.

That said, I understand the argument that people would like to keep some kind of "semantic" for string literals. One possibility is to keep ms in Core but says that it does not add automatic quotes (i.e. behave like mtext). People could write a CSS polyfill for non-RTL mode using the :before/:after rules or a JS polyfill that actually change the text content of ms.

I doubt ms is used much in "classical" mathematical texts but it is very natural when documenting programs or pseudocode etc where a "string" is usually just as primitive datatype as a "number"

but... I understand the concerns re picking up attributes.

One possibility is to keep ms in Core but says that it does not add automatic quotes (i.e. behave like mtext).

To make this slightly more distinguished from mtext it could default to monospace?

Also would the css concerns be as great if you dropped support for the attributes and always used a straight double quote " at each end? (I suspect it wouldn't help as much as I'd like as you would still be inserting text but I thought it worth asking...)

To make this slightly more distinguished from mtext it could default to monospace?

Adding default rule font-family: monospace; or text-transform: math-monospace; would work and not cause any issue.

Also would the css concerns be as great if you dropped support for the attributes and always used a straight double quote " at each end? (I suspect it wouldn't help as much as I'd like as you would still be inserting text but I thought it worth asking...)

Supporting only the default value still require to modify the tree which is not great for text selection, copy & paste, search or accessibily (I suspect Firefox's implementation is broken with that regard). However, it's true it allows to fix #126 since both quotes are the same.

I think I am coming round to the idea of dropping ms, Dropping the element entirely is easy to understand (and document) but if we put in a cut down ms that doesn't add text then

<ms>wibble</ms>

will or will not add quotes depending on whether it is interpreted by a full mathml system or mathml core.

So while given a choice I'd rather have ms, if it is causing you issues and time that would be better spent elsewhere, then this is a battle I don't want to fight:-)

@fred-wang

@fred-wang we briefly discussed this in the WG meeting today, 1/23/2025, and were wondering if you had any opinion on my last comment, or on the resolution in general.

@dginev

@dginev sorry, this thread is long. can you please summarize the discussion?

Summary

The top level issue is to resolve if <ms> can be deprecated and removed from MathML 4 Full.

I have an open low-level question whether we have a ready alternative via <mtext> and CSS open-quote and close-quote, as in this example. I wanted to confirm that is reasonable in general.
If it was possible to use open-quote and close-quote directly on <mtext> I could see that as sufficient for all MathML+CSS platforms and could suggest deprecating <ms>. Requiring HTML elements (such as a <span>) would likely lead to MathML Full keeping <ms> and suggesting to use a polyfill for it.
- Example 2 codepen: single <mtext> with display:inline;

The group has to decide if MathML Full should only warn <ms> is not in Core, or it should directly deprecate <ms> and schedule for removal down the line. And we wanted to freshly check that we know the details here.

* I have an open low-level question whether we have a ready alternative via `<mtext>` and CSS `open-quote` and `close-quote`, as [in this example](https://codepen.io/dginev/pen/azoQZeE). I wanted to confirm that is reasonable in general.

Talking only about layout behavior, this looks ok to me. As per https://w3c.github.io/mathml-core/#layout-of-mtext ; the span would trigger the "otherwise" case (i.e. normal block layout) which should be able to know how to deal with the anonymous boxes before and after the span.

I'm unsure if the order of quotes will be correct in RTL mode, and whether the quotes will be properly exposed to the a11y tree though.

But if the polyfill is going to generate a span, why not just change the innerText directly?

* If it was possible to use `open-quote` and `close-quote` directly on `<mtext>` I could see that as sufficient for all MathML+CSS platforms and could suggest deprecating `<ms>`. Requiring HTML elements (such as a `<span>`) would likely lead to MathML Full keeping `<ms>` and suggesting to use a polyfill for it.

In that case that would mean the anonymous boxes are before and after the mtext box, so the parent element will have to know how to deal with that and MathML Core does not say anything about that. I suspect this will be much more work to make that work, and so that goes against the argument that relying on a pure CSS-based implementation would just work.

  * [Example 2 codepen](https://codepen.io/dginev/pen/yyBQaoX): single `<mtext>` with `display:inline;`
The group has to decide if MathML Full should only warn <ms> is not in Core, or it should directly deprecate <ms> and schedule for removal down the line. And we wanted to freshly check that we know the details here.

ms in is in MathML Core: https://w3c.github.io/mathml-core/#string-literal-ms ; i think it's ok to keep it for backwards compat (it's also in the HTML5 parser spec I believe).

I think if MathML Full can say authors should write the quotes directly in the ms text, that would be best. But I guess I'll let people who care about MathML Full decide...

Make MMLbase support trees: Intermediate cleanup

Update git submodules

Bug 1599001 [wpt PR 20426] - Remove test for RTL ms and add test for …

@davidcarlisle

This was discussed today at the MathML Core meeting. The main points that were brought up were:

Full and Core are in conflict: full defaults to assuming open/close quotes and core defaults to not assuming quotes.
ms is in the parser and it is a leaf, and therefore an integration point with HTML. Therefore it has to stay in core (it can't be an unknown core element treated as mrow)
Changing full breaks legacy MathML. While ms might not be that common in general math, in specific contexts, it is quite common. @davidcarlisle mentioned in another call that his company's documentation has tens of thousands of instances of it because they are documenting code that does mathematical computations.
Using :before and :after can be problematic for copy/paste, but not for accessibility. However, copying MathML as plain text is going to fail in many circumstances (e.g., for fractions and a scripts), and even when copying linear text, italics and spacing will be lost. For ms, if it is copied in a MathML context, then the MathML should be copied and the quotes will be preserved.
We did not discuss the problems around RTL.

We did not resolve what should be done.

@fred-wang

* Using `:before` and `:after` can be problematic for copy/paste, but not for accessibility.

@fred-wang mentioned that this was an accessibility concern in #120 (comment). Was this ever resolved?

@SmashManiac

@SmashManiac this was based on the statements made in the original intents of the design of generated content. In practice, it is necessary to provide generated content to the accessibility tree, so that changed - but it diverged now with copy/paste, which used to match on this point.

Make the polyfill target <mtext> and that way we avoid problems as what core does with <ms>

I've made the polyfill target mtext.

Navigation Menu

Repository navigation

Remove/deprecate/simplify the ms element #120

35 remaining items

Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remove/deprecate/simplify the ms element #120

Description

Activity

davidcarlisle commented on Jul 17, 2019

bkardell commented on Jul 31, 2019

davidcarlisle commented on Jul 31, 2019

fred-wang commented on Sep 13, 2019

davidcarlisle commented on Sep 13, 2019

fred-wang commented on Sep 13, 2019

davidcarlisle commented on Sep 13, 2019

35 remaining items

dginev commented on Jan 23, 2025

fred-wang commented on Jan 24, 2025

dginev commented on Jan 24, 2025

Summary

fred-wang commented on Jan 24, 2025

NSoiffer commented on Jul 28, 2025

SmashManiac commented on Aug 1, 2025

bkardell commented on Aug 1, 2025

NSoiffer commented on Feb 19, 2026

NSoiffer commented on May 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions