Deprecate/Remove the `<mstyle>` element

[fred-wang]

Currently, it's strictly equivalent to the <mrow> element for layout purpose.

Similarly to what was @dginev proposed in https://github.com/w3c/mathml-core/issues/173 we probably want to remove the <mstyle> element from MathML Core and deprecate it from MathML Full.

[dginev]

I'm generally in favor of this proposal ( for the same "simpler is better" principle as with #173 ). If the original features intended for mstyle are now available via global attributes and implied reliance on CSS, that ought to be sufficient for removal from Core.

I am not sure if there are good arguments for retaining it in MathML Full, and if there is desire to allow an option for third-party rendering independent of CSS. If not, deprecation there sounds reasonable as well.

That said, there is a pending "twist" to the story. We have an ongoing internal discussion about repurposing mstyle for a new use with the intent mechanism, which may - or may not - gain support.

The basis for reuse was that the group thought leveraging an existing element is easier both technically and politically, compared to inventing a new one (and seeking support for addition into Core). But if that discussion doesn't gain traction, mstyle may have also outlived its usefulness.

[NSoiffer]

mstyle is not as simple to get rid of as none. In MathML full, mstyle accepts a large number of attributes, not the more limited set accepted by core. mrow on the other hand only accepts the global attributes in full.

I suppose one could consider allowing all of those attributes on mrow in full, but the idea of mstyle is to change defaults for its children and the idea of mrow is to layout the children horizontally. Since the two things are not normally used together, it seems like a design mistake to join them. Joining the ideas together is lessened a bit in core because of the restrictions on what mstyle can change. However that still leaves displaystyle, mathbackground, mathcolor, mathsize, mathvariant, and scriptlevel that conflate the idea of layout with the idea of changing defaults.

I wasn't aware or had forgotten that mathvariant and mathsize were allowed on any MathML element in core. That's not true in full. It seems particularly strange to allow mathvariant on anything besides a leaf element.

In summary, I'd like to hear why "overloading" mrow makes sense. If we are to make any changes to core, I'd like to see mathvariant restricted to only the leaf elements for which it makes sense. This would be more consistent with core's handling of other attributes such as linethickness, accent, and minsize.

[fred-wang]

In MathML <= 3, the idea of mstyle was to change the default value of attributes but it had several issues (e.g. having to deal conflicting attribute names, mathbackground originally not applied to the actual element, not really corresponding to actual CSS "style").

In MathML Core, the idea is instead to rely on CSS for styling. Ideally, all stylistic features should correspond to CSS properties and attributes would just mapped to style as presentational hints. This is unfortunately not possible for MathML features depending on the DOM content (operator dict and all) but at least the global ones are currently handled.

Regarding mathvariant, this is controversial because really only the automatic italicization of the single-char <mi> can be characterized as "stylistic". We failed to convince the CSS WG to extend text-transform for other attribute values, so we didn't implement them in chromium and a large amount of tests are failing. Googlers even suggested to remove this mathvariant thing to resolve that problem. My preference would be to just drop mathvariant from MathML Core (only keeping mathvariant="normal" on mi) and tell people to use proper Unicode code points instead.

Anyway, coming back to the actual issue, we can either remove <mstyle> from Core (and keep it in Full) or keep the current paragraph in Core. That won't make a difference implementation-wise. I only opened this for the record, since we did the same for <none>...

[dginev]

In summary, I'd like to hear why "overloading" mrow makes sense.

<mrow> may have been named in order to be suggestive for "layout the children horizontally", but it appears to be mostly used for grouping (of arguments, styled scopes, id-carrying subtrees that can be cross-referenced...), much akin to the grouping uses of <span> in HTML.

The children of a top-level <math> get laid out horizontally, which I think is the default for a range of elements - <msqrt>, <mtd>, <mpadded>, <mroot>, <mtext>, <mphantom>. More importantly, the children of an <mstyle> get laid out horizontally, which truly signals the association for "an mrow with styling directives", as in:

<mfrac>
  <mstyle mathcolor="red">
    <mi>x</mi>
    <mo>+</mo>
    <mi>y</mi>
  </mstyle>
  <mstyle mathcolor="green">
    <mi>y</mi>
    <mo>+</mo>
    <mi>z</mi>
  </mstyle>
</mfrac>

compare that to the equivalent:

<mfrac>
  <mrow style="color:red;">
    <mi>x</mi>
    <mo>+</mo>
    <mi>y</mi>
  </mrow>
  <mrow style="color:green;">
    <mi>y</mi>
    <mo>+</mo>
    <mi>z</mi>
  </mrow>
</mfrac>

To my current thinking, a good direction of long-term reconciliation with HTML is to increasingly think of an "mrow" element as a "math-y version of a span".

[davidcarlisle]

I think I'd remove mstyle from core. It's already described as acting like mrow with notes saying it's legacy compatibility with mathml full and shouldn't be used in new documents aimed at mathml-core processors.

It is used quite a bit by mathml generators but since the behaviour of an unknown element is also to act like mrow, the compatibility hit from removing mstyle is low, and mostly affects validators, and flagging it as invalid is on the whole a good thing.

If we remove it from the core spec it would be a minor adjustment to the schema described in mathml4 to move mstyle to those elements added by mathml4-presentation schema rather than inherited from core. (mainly mentioning that here so I remember to do it if needed)