Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplification of the mstyle element #1

Open
fred-wang opened this issue Feb 14, 2019 · 23 comments
Open

Simplification of the mstyle element #1

fred-wang 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

Comments

@fred-wang
Copy link

fred-wang commented Feb 14, 2019

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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

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
Copy link
Collaborator

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

@fred-wang fred-wang added MathML Core Issues affecting the MathML Core specification MathML 4 Issues affecting the MathML 4 specification labels Feb 22, 2019
@fred-wang fred-wang added the css / html5 Issues related to CSS or HTML5 interoperability label Feb 22, 2019
@dani31415
Copy link

dani31415 commented Feb 25, 2019

Why not indentalign -> text-align ?

@physikerwelt
Copy link
Member

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?

@fred-wang
Copy link
Author

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
Copy link
Author

fred-wang commented Mar 14, 2019

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
Copy link

dani31415 commented Mar 15, 2019

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
Copy link
Author

fred-wang commented Mar 19, 2019

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 fred-wang added the compatibility Issues affecting backward compatibility label Mar 20, 2019
@fred-wang
Copy link
Author

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.

@NSoiffer
Copy link
Contributor

NSoiffer commented Apr 29, 2019

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
Copy link
Author

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

@fred-wang fred-wang 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
fred-wang added a commit to web-platform-tests/wpt that referenced this issue Sep 17, 2019
fred-wang added a commit to web-platform-tests/wpt that referenced this issue Sep 17, 2019
…19110)

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

See w3c/mathml#1

* Avoid false positives.
@fred-wang fred-wang removed the need tests Issues related to writing WPT tests label Sep 17, 2019
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Sep 18, 2019
…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
dbaron pushed a commit to dbaron/gecko that referenced this issue Sep 19, 2019
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 4, 2019
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Oct 4, 2019
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 4, 2019
…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
caiolima pushed a commit to caiolima/webkit that referenced this issue Apr 11, 2020
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
Copy link
Contributor

NSoiffer commented May 20, 2020

Reopened because it still needs a polyfill.

@NSoiffer
Copy link
Contributor

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?

@NSoiffer NSoiffer added the need resolution Issues needing resolution at MathML Refresh CG meeting label Aug 17, 2020
@NSoiffer
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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.

ryanhaddad pushed a commit to WebKit/WebKit that referenced this issue Dec 22, 2020
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.

Canonical link: https://commits.webkit.org/223145@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@259785 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

5 participants