Simplification of the mstyle element

[fred-wang]

This proposal is to simplify mstyle so that it only supports the following attributes:

• displaystyle
• dir
• mathsize
• mathbackground
• mathcolor
• mathvariant
• scriptlevel

And maybe:

• scriptsizemultiplier
• scriptminsize

From the Math WG mailing list:
https://lists.w3.org/Archives/Public/www-math/2016Jul/0024.html

From the appendix of the original "MathML in HTML5" document:
"The mstyle element duplicates the CSS inheritance mechanism in a CSS-incompatible way and has many exceptions to workaround the fact that attribute names may be used for different purposes. In practice, many of its attributes are not useful and never used. It is a burden for implementers since they essentially have to reimplement a specific “attribute” inheritance mechanism to support the general case even if the most prominent attributes have obvious mapping to CSS. It is also a performance issue to perform the rendering and keep it up-to-date since the rendering on any node may depend on its mstyle ancestors. In this document, it instead suggested to keep only attributes that are compatible with CSS and five new CSS properties are introduced in section 2.3.1. These attributes actually correspond to what is used in practice. "

edit:
This is the proposal for CSS attributes that cannot be mapped to style yet: https://github.com/mathml-refresh/mathml-css-proposals#mathml-css-proposals

[physikerwelt]

This might be a stupid question, but why do we need

• dir -> direction
• mathsize -> font-size
• mathbackground -> background-color
• mathcolor -> color
  can that not implemented using the style attribute?

[fred-wang]

Yes, they can be (and are) implemented using CSS style.
Whether we want to remove/deprecate these MathML attributes (and hence the whole mstyle element) is another question, but probably they have already been used a lot in existing documents. This is not really the case of attributes not mentioned in #1 (comment) , I think in a previous discussion on Math WG only one instance of another attribute (linethickness) was used in the MathML 3 test suite.

[fred-wang]

Incidentally, for attributes without CSS equivalent, there is https://github.com/mathml-refresh/mathml-css-proposals#mathml-css-proposals

@physikerwelt I think in general it would be good to gather usage metrics of elements/attributes that are proposed for deprecation/removal. Maybe you can do that for wikipedia.

[davidcarlisle]

This might be a stupid question, but why do we need

* dir -> direction

* mathsize -> font-size

* mathbackground -> background-color

* mathcolor -> color
  can that not implemented using the style attribute?

html also has a dir attribute so this isn't so strange I think?

Initially the model was to preserve as far as possible that as far as possible the notion that css should be used to encode potentially reader-customizable style, and that explicit attributes in the source should be used to encode author-specified meaning.

So a clearer example would be <mi mathvariant="sans-serif" to chose a sans math alphabet as opposed to using CSS to chose the overall font style (which may be sans serif)

Of course in the end mathvariant got defined as a shift of codepoint rather than a change of font, but it was still a motivating example here.

So at the time, almost all publications were monochrome but the thought was that you may want to use colour just as fonts have been traditionally used, to have distinguished mathematical variables x mathcolor="red" and x mathcolor="blue" that are separate from a reader choice to style the whole expression in brown to match a website style...

We can decide not to keep this (and we could potentially have different decision for the mathml-core and full mathml but if you are asking why mathml3 (and 2 and 1) are this way, that is basically why.

[dani31415]

Why not indentalign -> text-align ?

[physikerwelt]

discussed in the telco on 2019-02-25:

• @NSoiffer does not think one can get rid of mstyle entirely?
  ** @fred-wang "in theory one could get rid of mstyle and use style of mrow"
• can one get rid of matvariant?
• patrick ion asks if there are glyphs that are only accessible via mstyle?

[fred-wang]

Why not indentalign -> text-align ?

I don't think indentalign is in MathML Core. Also we should keep in mind (2) #30 (comment) applies here.

[fred-wang]

This is how I understand the current status:
(1) Do we keep the <mstyle> element? It could just be <mrow> + CSS styles but we need (a) to define more CSS properties / remove some attributes and (b) take into account non-browser implementation and backward compatibility with existing usage #55.
(2) Do we reduce the existing set of properties (suggestion: #1 (comment)).
(3) Do we just map properties to CSS instead of defining our own inheritance?
(4) Do we move new proposals https://github.com/mathml-refresh/mathml-css-proposals to CSS -drafts?. Per https://lists.w3.org/Archives/Public/public-mathml4/2019Mar/0007.html for mathvariant it seems fine to extend CSS text-transform and displaystyle is not really controversial. I hope we can decide about scriptlevel-related properties in the next meeting.

[dani31415]

I think we should make MathML core as much backward compatibility as possible with existing formulas. With this idea we should implement the <mstyle>.

At the same time I would deprecate <mstyle> in the sense that we recommend to use the alternative version of <mrow> with CSS. In addition, in MathML 4, I would deprecate <mstyle> as well (with the same meaning of a recommendation of not to use it).

[fred-wang]

cc @rwlbuis @emilio

We have discussed a lot about scriptlevel yesterday. This is my summary regarding the attributes:

• CSS engines need to know about scriptlevel, scriptsizemultiplier and scriptminsize which means we would need to map attributes to CSS or replace them with something known by CSS.
• Putting scriptsizemultiplier and scriptminsize in an arbitrary place is not very useful (but if we map them to CSS that would still be possible anyway). In general some people think it does not make sense to configure scriptsizemultiplier and scriptminsize values at the MathML markup level, there should be another more modern way to address these use cases.
• For the first script levels, the scriptsizemultiplier feature could be replaced with OpenType MATH scriptPercentScaleDown and scriptScriptPercentScaleDown constants which are likely accessible from the CSS engine and correspond more to the font designer's goal. Other levels are less important in practice (e.g. TeX and Microsoft office don't consider them) so we could keep the constant 0.71 or do another kind of extrapolation. See https://github.com/mathml-refresh/mathml-css-proposals/blob/master/math-script-level-and-math-style-comments.md#opentype-math-values-scriptpercentscaledown-and-scriptscriptpercentscaledown
• the scriptminsize feature could probably be replaced with CSS's new font-min-size property ( https://drafts.csswg.org/css-fonts-4/#propdef-font-min-size ). Note that this is not exactly the same, since scriptminsize is only supposed to affect the change due to scriptlevel, so we cannot just map to font-min-size. However, I believe it still addresses the use cases for which scriptminsize was introduced.

Given all of this, I would now recommend to remove scriptsizemultiplier and scriptminsize attributes from MathML Core and only keep thoses:

• displaystyle (mapped to a new two-valued CSS property)
• dir
• mathsize
• mathbackground
• mathcolor
• mathvariant (mapped to new text-transform values)
• scriptlevel (mapped to a new property)

Details for the last one still have to be discussed in #31

[fred-wang]

@brucemiller mentioned that LaTeXML sometimes generates href on mstyle ( #55 (comment) ).

First, I'd like to clarify that this proposal is not about generic MathML attributes on mstyle ( like https://mathml-refresh.github.io/mathml/chapter2.html#fund.globatt or https://mathml-refresh.github.io/mathml/chapter3.html#presm.presatt ) but only about those related to this MathML 3 "inheritance".

Also, this raises yet another issue with the MathML 3 mstyle model. https://mathml-refresh.github.io/mathml/chapter3.html#presm.mstyle already has an exception for mathbackground/mathcolor saying that it applies to the mstyle itself, not to descendants. Such an exception should also apply to href.

[NSoiffer]

Resolution of 29/4/19 meeting: ( https://lists.w3.org/Archives/Public/public-mathml4/2019Apr/0022.html )

• scriptsizemultiplier, scriptminsize: remove from core. Rely rely on opentype math table for scriptsizemultiplier; use css property for scriptminsize

• dir, mathsize, mathbackground, mathcolor: keep in core and map to the corresponding CSS property:

[fred-wang]

Resolution:
#1 (comment)

Specification:
Need to update Core spec to describe the mappings.
Need to update Full spec to deprecate attributes (?)

Implementation:
Need to remove deprecated attributes ( #5 ), need to implement new CSS properties and to map them to CSS ( #31 ). Other attributes are not implemented.

Polyfill:
Need to write some polyfill implementing https://mathml-refresh.github.io/mathml/chapter3.html#presm.mstyle

Tests:

• Check attributes on mstyle/math tags are supported ; and that others are not.
• Check rendering equivalence with CSS properties.
• Check the actual CSS mapping via getComputedStyle()
• Check inheritance/overriding with several nested mstyle
• Check interaction of mstyle attributes with the equivalent CSS properties
• Check default values
• Check adding/removing attributes / CSS properties dynamically
• ...

[NSoiffer]

Reopened because it still needs a polyfill.

[NSoiffer]

#204 asks some questions about inheritance and mathvariant. In a comment, @fred-wang mentioned people really should use mathvariant only on token elements. To me, that raises the question of why mathvariant is still settable on mstyle. It doesn't seem particularly useful and it seems to raise some issues.

Since mstyle is being simplified for core, why not remove mathvariant from it?

[NSoiffer]

Discussed briefly at the Aug 17 and people generally felt that mathvariant doesn't make sense to remain on mstyle. Will discuss more fully at next meeting.

[fred-wang]

The logic in mathml core is that all the remaining mstyle attributes are now mapped to CSS and can be attached to any MathML elements. So I don't understand what's discussed here. In general it does not make any sense to talk about mstyle specifically for mathml core, since it's now strictly equivalent to an mrow. As I said on #204 , if this is an issue then it should be fixed for all elements, not mstyle specifically (i.e. use universal selectors).

[fred-wang]

I had removed the "mathml core" label BTW, as the simplification is done for mathml core. the only reason why this is still opened is whether there is a need for a polyfill or changes in mathml full.

[NSoiffer]

The point is to remove mathvariant as a global attr because it mostly only makes sense when placed on a specific token element to effect a mapping to a different code point. Even for that use, the proper Unicode glyph should have been used. It is unclear why this value was included in the original proposal's "keep" list.

[fred-wang]

This was discussed last year and we agreed to make all the mstyle attributes global because it's just easy to map attributes to style without doing all these tag-specific checks to know which element supports what. About completely removing mathvariant, this was also discussed last year and we agreed to keep it in the list because it's still widely used (even if using the proper unicode code point would be better, many tools don't do that). Finally we already have tests for these and implementation changes (I think at least in Chromium).

[NSoiffer]

In the last comment on this (Apr 2019) which is about a meeting resolution, only dir, mathsize, mathbackground, mathcolor were listed as being agreed to keep in core. mathvariant is not on the list.

I agree mathvariant is still used, but I don't believe anyone ever sets it on mstyle as it is not a useful thing to do. I don't think we have statistics on its usage on mstyle though so we don't have any info on that front to use in this discussion.

Also, it isn't clear that CSS will support the text-transform change needed as it is not in the latest working draft of CSS Text Module Level 3 so the current Chromium implementation may not be supportable on all platforms.

[fred-wang]

In the last comment on this (Apr 2019) which is about a meeting resolution, only dir, mathsize, mathbackground, mathcolor were listed as being agreed to keep in core. mathvariant is not on the list.

This github comment is not complete, the proposal was #1 (comment) and summary says

• maps displaystyle, mathvariant, scriptlevel to CSS
• remove scriptsizemultiplier and scriptminsize
• dir, mathsize, mathbackground, mathcolor: map attribute to existing CSS property
• Remove all the other mstyle attributes

which is what we've try to do in the spec/tests/implementation.

I agree mathvariant is still used, but I don't believe anyone ever sets it on mstyle as it is not a useful thing to do. I don't think we have statistics on its usage on mstyle though so we don't have any info on that front to use in this discussion.

Two points:

• AFAIK MathJax (and so wikipedia) does not use Unicode characters, but the mathvariant attribute instead. And there are others tools using mstyle@mathvariant (like itex2MML). So we would need to convince them first or claim polyfill is good enough in that case.

• As discussed during core meeting, restricting to token elements actually makes things more slightly complicate for browsers since you need to perform per-tag check and have the corresponding tests to check attributes apply to a specific list of elements. So I still don't understand what's the point of doing that? The only explanation is #204 but it can be solved by introducing universal selector, if it's considered a bug rather than a feature. I also prefer consistency and say that "MathML stylistic attributes apply to all mathml elements and are just mapped to CSS properties" which is easy to understand.

Also, it isn't clear that CSS will support the text-transform change needed as it is not in the latest working draft of CSS Text Module Level 3 so the current Chromium implementation may not be supportable on all platforms.

We definitely need automatic mathvariant italic in any case for single-char mi. If the CSS WG rejects or wants change to mathvariant or other proposals then we can adapt accordingly, but I don't think we need to agree before we actually get their feedback. Also IIUC Brian said our text-transform proposal is uncontroversial in the CSSWG now. I think the risk is more on the scriptlevel stuff.