/ mathml Public

# Simplification of the mstyle element#1

Open
opened this issue Feb 14, 2019 · 23 comments
Open

# Simplification of the mstyle element #1

opened this issue Feb 14, 2019 · 23 comments
Labels
compatibility Issues affecting backward compatibility css / html5 Issues related to CSS or HTML5 interoperability MathML 4 Issues affecting the MathML 4 specification need polyfill Issues requiring implementation changes need resolution Issues needing resolution at MathML Refresh CG meeting need specification update Issues requiring specification changes

### fred-wang commented Feb 14, 2019 • edited

 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 The text was updated successfully, but these errors were encountered:

### physikerwelt commented Feb 19, 2019

 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 commented Feb 19, 2019

 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 commented Feb 19, 2019

 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 commented Feb 19, 2019

 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

mentioned this issue Feb 20, 2019
added MathML Core Issues affecting the MathML Core specification MathML 4 Issues affecting the MathML 4 specification labels Feb 22, 2019
mentioned this issue Feb 22, 2019
added the css / html5 Issues related to CSS or HTML5 interoperability label Feb 22, 2019

### dani31415 commented Feb 25, 2019

 Why not indentalign -> text-align ?

### physikerwelt commented Feb 25, 2019

 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?

mentioned this issue Feb 25, 2019

### fred-wang commented Mar 14, 2019

 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 commented Mar 14, 2019

 This is how I understand the current status: (1) Do we keep the  element? It could just be  + 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 commented Mar 15, 2019 • edited

 I think we should make MathML core as much backward compatibility as possible with existing formulas. With this idea we should implement the . At the same time I would deprecate  in the sense that we recommend to use the alternative version of  with CSS. In addition, in MathML 4, I would deprecate  as well (with the same meaning of a recommendation of not to use it).

mentioned this issue Mar 19, 2019

### fred-wang commented Mar 19, 2019

 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

mentioned this issue Mar 20, 2019
added the compatibility Issues affecting backward compatibility label Mar 20, 2019

### fred-wang commented Mar 22, 2019

 @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.

mentioned this issue Apr 25, 2019

### NSoiffer commented Apr 29, 2019 • edited by fred-wang

 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:

This was referenced May 7, 2019

### fred-wang commented May 16, 2019

 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 ...

added need implementation update need polyfill Issues requiring implementation changes need specification update Issues requiring specification changes need tests Issues related to writing WPT tests labels May 16, 2019
mentioned this issue May 29, 2019
added a commit to web-platform-tests/wpt that referenced this issue Sep 17, 2019
 Add MathML tests to check that legacy mstyle attributes are ignored. 
 8ac2b47 
See w3c/mathml#1
mentioned this issue Sep 17, 2019
added a commit to web-platform-tests/wpt that referenced this issue Sep 17, 2019
 Add MathML tests to check that legacy mstyle attributes are ignored. (#… 
 0d0f931 
…19110)

* Add MathML tests to check that legacy mstyle attributes are ignored.

See w3c/mathml#1

* Avoid false positives.
removed the need tests Issues related to writing WPT tests label Sep 17, 2019
pushed a commit to mozilla/gecko-dev that referenced this issue Sep 18, 2019
 Bug 1581726 [wpt PR 19110] - Add MathML tests to check that legacy ms… 
 f0716a8 
…tyle attributes are ignored., a=testonly

Automatic update from web-platform-tests
Add MathML tests to check that legacy mstyle attributes are ignored. (#19110)

* Add MathML tests to check that legacy mstyle attributes are ignored.

See w3c/mathml#1

* Avoid false positives.

--

wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c
wpt-pr: 19110
pushed a commit to dbaron/gecko that referenced this issue Sep 19, 2019
 Bug 1581726 [wpt PR 19110] - Add MathML tests to check that legacy ms… 
 c6ef8ec 
…tyle attributes are ignored., a=testonly

Automatic update from web-platform-tests
Add MathML tests to check that legacy mstyle attributes are ignored. (#19110)

* Add MathML tests to check that legacy mstyle attributes are ignored.

See w3c/mathml#1

* Avoid false positives.

--

wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c
wpt-pr: 19110
pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 4, 2019
 Bug 1581726 [wpt PR 19110] - Add MathML tests to check that legacy ms… 
 bda7361 
…tyle attributes are ignored., a=testonly

Automatic update from web-platform-tests
Add MathML tests to check that legacy mstyle attributes are ignored. (#19110)

* Add MathML tests to check that legacy mstyle attributes are ignored.

See w3c/mathml#1

* Avoid false positives.

--

wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c
wpt-pr: 19110

UltraBlame original commit: 264ac2242a393e4691d45c7704d7c807b8516ef9
pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 4, 2019
 Bug 1581726 [wpt PR 19110] - Add MathML tests to check that legacy ms… 
 9282579 
…tyle attributes are ignored., a=testonly

Automatic update from web-platform-tests
Add MathML tests to check that legacy mstyle attributes are ignored. (#19110)

* Add MathML tests to check that legacy mstyle attributes are ignored.

See w3c/mathml#1

* Avoid false positives.

--

wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c
wpt-pr: 19110

UltraBlame original commit: 264ac2242a393e4691d45c7704d7c807b8516ef9
pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 4, 2019
 Bug 1581726 [wpt PR 19110] - Add MathML tests to check that legacy ms… 
 8a4428e 
…tyle attributes are ignored., a=testonly

Automatic update from web-platform-tests
Add MathML tests to check that legacy mstyle attributes are ignored. (#19110)

* Add MathML tests to check that legacy mstyle attributes are ignored.

See w3c/mathml#1

* Avoid false positives.

--

wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c
wpt-pr: 19110

UltraBlame original commit: 264ac2242a393e4691d45c7704d7c807b8516ef9
pushed a commit to caiolima/webkit that referenced this issue Apr 11, 2020
 Remove unnecessary explicit parsing for mo@maxsize value "infinity" 
 cae4b6d 
https://bugs.webkit.org/show_bug.cgi?id=202720

Patch by Delan Azabani <dazabani@igalia.com> on 2020-04-09
Reviewed by Frédéric Wang.

In MathML 2, the default mo@maxsize was infinity [1], unless some other
default was given by mstyle@maxsize [2]. The sole purpose of "infinity"
was to give authors a way to set mo@maxsize to infinity when some other
mstyle@maxsize was set.

MathML Core removes mstyle@maxsize [3][4], such that "infinity" has the
same semantics as any other missing or invalid mo@maxsize, so the spec
has been simplified to make infinity an anonymous value [5][6].

No functional change, because WebKit has never supported mstyle@maxsize
anyway. To verify that there's no functional change:

1.  Search for references to LengthType::Infinity, and observe that the
mo@maxsize parser in MathMLOperatorElement::maxSize is the only
place where a Length of ::type infinity is created
2.  Search for references to that method, and observe that the only
caller (RenderMathMLOperator::maxSize) passes intMaxForLayoutUnit
(infinity) to toUserUnits as the referenceValue
3.  Go to the definition of toUserUnits, and observe that the refer-
enceValue is used as the ParsingFailed default
4.  Step 1 shows that no other attributes would be affected by removing
LengthType::Infinity, and steps 2 and 3 show that mo@maxsize treats
invalid values as infinity, therefore it's safe to remove both the
"infinity" parsing code and the underlying LengthType variant

[1] https://www.w3.org/TR/MathML2/chapter3.html#id.3.2.5.2
[2] https://www.w3.org/TR/MathML2/chapter3.html#presm.mstyle
[3] https://mathml-refresh.github.io/mathml-core/#style-change-mstyle
[4] w3c/mathml#1
[5] https://mathml-refresh.github.io/mathml-core/#dictionary-based-attributes
[6] w3c/mathml#107

No new tests, because no functional change.

* mathml/MathMLElement.h: Remove LengthType::Infinity.
* mathml/MathMLOperatorElement.cpp:
(WebCore::MathMLOperatorElement::maxSize): Remove explicit branch on "infinity". Replace what remains with an equivalent cachedMathMLLength call.
* rendering/mathml/RenderMathMLBlock.cpp:
(WebCore::toUserUnits): Remove explicit branch on LengthType::Infinity.
* rendering/mathml/RenderMathMLOperator.cpp:
(WebCore::RenderMathMLOperator::maxSize): Update comment to refer to the default value in the same way as the spec.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@259785 268f45cc-cd09-0410-ab3c-d52691b4dbfc

### NSoiffer commented May 20, 2020

 Reopened because it still needs a polyfill.

reopened this May 20, 2020
removed the MathML Core Issues affecting the MathML Core specification label May 22, 2020
mentioned this issue May 24, 2020

### NSoiffer commented Aug 17, 2020

 #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?

added the need resolution Issues needing resolution at MathML Refresh CG meeting label Aug 17, 2020

### NSoiffer commented Aug 18, 2020

 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 commented Aug 18, 2020

 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 commented Aug 18, 2020

 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 commented Aug 18, 2020

 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 commented Aug 18, 2020

 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 commented Aug 19, 2020

 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 commented Aug 19, 2020

 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.

pushed a commit to WebKit/WebKit that referenced this issue Dec 22, 2020
 Remove unnecessary explicit parsing for mo@maxsize value "infinity" 
 21d6639 
https://bugs.webkit.org/show_bug.cgi?id=202720

Patch by Delan Azabani <dazabani@igalia.com> on 2020-04-09
Reviewed by Frédéric Wang.

In MathML 2, the default mo@maxsize was infinity [1], unless some other
default was given by mstyle@maxsize [2]. The sole purpose of "infinity"
was to give authors a way to set mo@maxsize to infinity when some other
mstyle@maxsize was set.

MathML Core removes mstyle@maxsize [3][4], such that "infinity" has the
same semantics as any other missing or invalid mo@maxsize, so the spec
has been simplified to make infinity an anonymous value [5][6].

No functional change, because WebKit has never supported mstyle@maxsize
anyway. To verify that there's no functional change:

1.  Search for references to LengthType::Infinity, and observe that the
mo@maxsize parser in MathMLOperatorElement::maxSize is the only
place where a Length of ::type infinity is created
2.  Search for references to that method, and observe that the only
caller (RenderMathMLOperator::maxSize) passes intMaxForLayoutUnit
(infinity) to toUserUnits as the referenceValue
3.  Go to the definition of toUserUnits, and observe that the refer-
enceValue is used as the ParsingFailed default
4.  Step 1 shows that no other attributes would be affected by removing
LengthType::Infinity, and steps 2 and 3 show that mo@maxsize treats
invalid values as infinity, therefore it's safe to remove both the
"infinity" parsing code and the underlying LengthType variant

[1] https://www.w3.org/TR/MathML2/chapter3.html#id.3.2.5.2
[2] https://www.w3.org/TR/MathML2/chapter3.html#presm.mstyle
[3] https://mathml-refresh.github.io/mathml-core/#style-change-mstyle
[4] w3c/mathml#1
[5] https://mathml-refresh.github.io/mathml-core/#dictionary-based-attributes
[6] w3c/mathml#107

No new tests, because no functional change.

* mathml/MathMLElement.h: Remove LengthType::Infinity.
* mathml/MathMLOperatorElement.cpp:
(WebCore::MathMLOperatorElement::maxSize): Remove explicit branch on "infinity". Replace what remains with an equivalent cachedMathMLLength call.
* rendering/mathml/RenderMathMLBlock.cpp:
(WebCore::toUserUnits): Remove explicit branch on LengthType::Infinity.
* rendering/mathml/RenderMathMLOperator.cpp:
(WebCore::RenderMathMLOperator::maxSize): Update comment to refer to the default value in the same way as the spec.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@259785 268f45cc-cd09-0410-ab3c-d52691b4dbfc
mentioned this issue Jun 28, 2021
mentioned this issue Jun 29, 2021
mentioned this issue Mar 4, 2022
mentioned this issue Mar 30, 2022