Remove mathvariant from core (except 'normal') #182

NSoiffer · 2022-12-15T19:26:44Z

I'm starting a new issue based on a side topic mentioned in #181:

Regarding mathvariant, this is controversial because really only the automatic italicization of the single-char 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.

The Math WG (full) discussed this today and the reluctant resolution is that now is a good time has come to get rid of mathvariant from core, especially since it sounds like it can't be supported in core.

mathvariant="normal" does need to be kept. It is a little strange to have an attribute with that name, but it, like many things in other languages, has that name because of history.

The text was updated successfully, but these errors were encountered:

dginev · 2022-12-15T21:32:30Z

This may be an opportune place and time to ask early a connected question:

Are these two formulations identical in MathML Core + CSS, by default?
And are they meant to be identical?

<mi mathvariant="normal">x</mi>

<mi style="text-transform:none;">x</mi>

NSoiffer · 2022-12-15T23:16:46Z

I'll leave that question to @fred-wang to answer.

I just spotted that MDN includes text-transform values math-auto, math-bold, etc. As @fred-wang said, I thought these were rejected. Is MDN wrong or did I (we?) miss something?

What is different is <mi style="font-style: normal">x</mi>. mathvariant is saying I want U+1D431 where as the style change is getting the ASCII 'x'.

There is hopefully a WPT test to make sure that style="font-style: italic" doesn't change the character used for rendering when a char in the math alphanumeric block is used, explicitly or in the case of mathvariant="normal", implicitly.

fred-wang · 2022-12-16T08:25:06Z

@dginev: Yes and yes for MathML Core, the spec says to treat mathvariant="normal" as a presentational hint text-transform: none: https://w3c.github.io/mathml-core/#the-mathvariant-attribute. However, WebKit and Firefox don't implement (automatic) mathvariant via text-transform yet, so we probably want to keep mathvariant="normal" for now anyway. Implementation-wise it is very small amount of code to map it to text-transform: none.

@NSoiffer MDN automatically parses the MathML Core spec to generate the documentation of formal definition/syntax but really the CSS WG only approved math-auto. So that's another reason to remove it ASAP and avoid misleading users with bad documentation when Chromium is released.

I didn't get what you mean but in MathML Core font-style/font-weight are totally orthogonal to mathvariant: the former properties specify the type of font used, the latter the unicode character used. Actually they were some hacks in Firefox to deal with conflicts with the legacy fontstyle/fontweight attributes, but they were causing more bugs and have been removed. So for example:

<mi style="font-style: normal">x</mi> is normally the same as <mi>x</mi> which is rendered as U+1D431 taken from a normal font.
<mi style="font-style: italic">x</mi> is rendered as U+1D431 taken from an italic font.
<mi style="font-weight: bold">x</mi> is rendered as U+1D431 taken from a bold font.
<mi style="font-style: italic; font-weight: bold">x</mi> is rendered as U+1D431 taken from a bold-italic font.
<mi style="font-style: normal">sin</mi> is normally the same as <mi>sin</mi> which is rendered as ASCII "sin" with a normal font.
<mi style="font-style: italic">sin</mi> is rendered as ASCII "sin" with an italic font.
<mi style="font-style: bold">sin</mi> is rendered as ASCII "sin" with a bold font.
<mi style="font-style: italic; font-weight: bold">sin</mi> is rendered as ASCII "sin" with a bold-italic font.
<mi style="font-style: italic; text-transform: none">x</mi> is rendered as ASCII 'x' taken from an italic font.
<mi style="font-weight: bold; text-transform: uppercase">x</mi> is rendered as ASCII 'X' taken from a bold font.
etc

(they are more subtilities with font-weight/font-style, like they can probably try to programmatically italicize/boldify a glyph from the normal font if bold/italic/bold-italic fonts don't provide the proper glyph, or rely on a single variable font to perform these transformations, but again all of these is out of the scope of the MathML Core spec and is specified elsewhere)

fred-wang · 2023-02-10T08:14:11Z

I wonder what's the status of this? It's currently one of the biggest issue for web-platform-tests/interop#197 (comment)

dginev · 2023-02-10T14:36:15Z

@fred-wang I believe as far as the WG was concerned, we resolved to remove mathvariant except for mathvariant="normal" on Dec 15th, and considered our job done.

Maybe the word "reluctant" in the description was misleading - there was group consensus to move forward with the removal. I am not aware of other WG activity since, except for our clarifying questions above.

My guess is that the next step here is to make the changes to the Core text.

#182

fred-wang · 2023-02-13T13:31:25Z

Spec updated.

We need to remove tests. However, WebKit/Firefox still implement the mathvariant attribute so they need to copy the tests in their internal suites.

fred-wang · 2023-02-14T09:40:10Z

Was the consensus to keep mathvariant as a global attribute (as in the current spec) or just an attribute for the mi element (as in my initial comment)?

w3c/mathml-core#182 - mathml/tools/utils/mathfont.py: migrate to Python 3. - mathml/tools/mathvariant-transforms.py: Convert the loop generating the CSS and MathML tests into a helper function. For MathML, we continue to call it for all mathvariant values until these tests are imported into WebKit/Mozilla. For CSS, we only keep the math-auto tests and remove the "tentative" in the name. - css/css-text/text-transform/math/text-transform-math-*: Tests removed, or renamed to drop the tentative in the name (for math-auto). After regeneration, the code points are properly sorted. - mathml/relations/css-styling/mathvariant-*.html: Keep them for now. After regeneration, the code points are properly sorted.

fred-wang · 2023-02-14T09:47:38Z

I just submitted a PR to start updating the tests. But for attribute-mapping-002.html I need to know whether mathvariant would still be global or mi-specific.

dginev · 2023-02-14T12:56:42Z

Was the consensus to keep mathvariant as a global attribute (as in the current spec) or just an attribute for the mi element (as in my initial comment)?

As far as I recall, we did not discuss a restriction to mi.

Maybe we could sneak that question in for this Thursday @NSoiffer ?

NSoiffer · 2023-02-14T21:06:18Z

Somewhere along the line I said it didn't make sense for it to be a global attr as it is very specific to the mi element. So I agree with @fred-wang initial inclination.

I can add this to the agenda for the meeting on Thursday.

davidcarlisle · 2023-02-15T10:38:13Z

Somewhere along the line I said it didn't make sense for it to be a global attr as it is very specific to the mi element. So I agree with @fred-wang initial inclination.

I can add this to the agenda for the meeting on Thursday.

the unicode math alphabet blocks include digits so it's quite natural to use mathvariant on mn to get 𝟙 or whatever, and I've certainly used that in the past. But since the proposal is to only allow the value normal which is default anyway for mn it makes sense to restrict to mi at the same time.

#182

dginev · 2023-02-16T19:09:05Z

@fred-wang the group discussed this today and we had consensus to accept your suggestion.

Namely, restrict mathvariant as an attribute only allowed on the mi element in MathML Core.
And we are still in agreement about mathvariant="normal" as the only defined value.

NSoiffer · 2023-02-17T00:53:05Z

We discussed this at the meeting today and agreed that since mathvariant='normal' if only useful on mi`, it should be a local attr for it.

fred-wang · 2023-02-24T07:48:51Z

Thanks, I'll update the spec and test PR.

#182

See w3c/mathml-core#182 - mathml/tools/utils/mathfont.py: migrate to Python 3. - mathml/tools/mathvariant-transforms.py: Convert the loop generating the CSS and MathML tests into a helper function. For MathML, we continue to call it for all mathvariant values until these tests are imported into WebKit/Mozilla. For CSS, we only keep the math-auto tests and remove the "tentative" in the name. - css/css-text/text-transform/math/text-transform-math-*: Tests removed, or renamed to drop the tentative in the name (for math-auto). After regeneration, the code points are properly sorted. - mathml/relations/css-styling/mathvariant-*.html: The only test that aligns with the latest version of MathML Core is mathvariant-auto.html but as said above, we keep the other tests for now until these tests are imported into WebKit/Mozilla. After regeneration, the code points are properly sorted. - mathml/relations/css-styling/attribute-mapping-002.html: We cannot test with fraktur/double-struck anymore. Instead, rely on inheritance of text-transform on the parent. Note that mathvariant mapping is now only done for the <mi> element.

bkardell · 2023-02-27T18:09:33Z

Reviewing this in the meeting today, we think we can close this and trust that @fred-wang will correct us and reopen if we're wrong.

The Math WG decided in [1] to remove support for the new text-transform values (except math-auto) and for mathvariant (except "normal" on <mi>). WPT tests have been updated accordingly in [2] but tests needed by Firefox/WebKit to check their mathvariant implementation have been kept until they are imported to their internal repos. This CL updates our mathvariant implementation accordingly and tweak the parts that were assuming full mathvariant support in the future (bug 1076420). mathml_element/mathml_token_element: Mathvariant is no longer a global attribute, but only supported on the `<mi>` element. It also only takes value "normal". So remove the TODO and place mapping in the subclass instead. style/computed_style.cc: Only `text-transform: math-auto` remains, so remove the TODO and rename the helper function ApplyMathAutoTransform. math_transform_fuzzer.cc/math_transform.cc: Only italic transform is performed, so remove the TODO and rename the function ItalicMathVariant. third_party/blink/web_tests/TestExpectations: Update expectations. Bug: 1076420 [1] w3c/mathml-core#182 [2] web-platform-tests/wpt#38490 Change-Id: If9f4530c23db60f50816785a6a87c05ae13e09fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4288752 Commit-Queue: Frédéric Wang <fwang@igalia.com> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1113453}

…ues, except math-auto, a=testonly Automatic update from web-platform-tests Remove text-transform tests for math values, except math-auto (#38490) See w3c/mathml-core#182 - mathml/tools/utils/mathfont.py: migrate to Python 3. - mathml/tools/mathvariant-transforms.py: Convert the loop generating the CSS and MathML tests into a helper function. For MathML, we continue to call it for all mathvariant values until these tests are imported into WebKit/Mozilla. For CSS, we only keep the math-auto tests and remove the "tentative" in the name. - css/css-text/text-transform/math/text-transform-math-*: Tests removed, or renamed to drop the tentative in the name (for math-auto). After regeneration, the code points are properly sorted. - mathml/relations/css-styling/mathvariant-*.html: The only test that aligns with the latest version of MathML Core is mathvariant-auto.html but as said above, we keep the other tests for now until these tests are imported into WebKit/Mozilla. After regeneration, the code points are properly sorted. - mathml/relations/css-styling/attribute-mapping-002.html: We cannot test with fraktur/double-struck anymore. Instead, rely on inheritance of text-transform on the parent. Note that mathvariant mapping is now only done for the <mi> element. -- wpt-commits: 08bac45e83cdf9980c00db1e94c0d385d0ca28c3 wpt-pr: 38490

See w3c/mathml-core#182 - mathml/tools/utils/mathfont.py: migrate to Python 3. - mathml/tools/mathvariant-transforms.py: Convert the loop generating the CSS and MathML tests into a helper function. For MathML, we continue to call it for all mathvariant values until these tests are imported into WebKit/Mozilla. For CSS, we only keep the math-auto tests and remove the "tentative" in the name. - css/css-text/text-transform/math/text-transform-math-*: Tests removed, or renamed to drop the tentative in the name (for math-auto). After regeneration, the code points are properly sorted. - mathml/relations/css-styling/mathvariant-*.html: The only test that aligns with the latest version of MathML Core is mathvariant-auto.html but as said above, we keep the other tests for now until these tests are imported into WebKit/Mozilla. After regeneration, the code points are properly sorted. - mathml/relations/css-styling/attribute-mapping-002.html: We cannot test with fraktur/double-struck anymore. Instead, rely on inheritance of text-transform on the parent. Note that mathvariant mapping is now only done for the <mi> element.

…ues, except math-auto, a=testonly Automatic update from web-platform-tests Remove text-transform tests for math values, except math-auto (#38490) See w3c/mathml-core#182 - mathml/tools/utils/mathfont.py: migrate to Python 3. - mathml/tools/mathvariant-transforms.py: Convert the loop generating the CSS and MathML tests into a helper function. For MathML, we continue to call it for all mathvariant values until these tests are imported into WebKit/Mozilla. For CSS, we only keep the math-auto tests and remove the "tentative" in the name. - css/css-text/text-transform/math/text-transform-math-*: Tests removed, or renamed to drop the tentative in the name (for math-auto). After regeneration, the code points are properly sorted. - mathml/relations/css-styling/mathvariant-*.html: The only test that aligns with the latest version of MathML Core is mathvariant-auto.html but as said above, we keep the other tests for now until these tests are imported into WebKit/Mozilla. After regeneration, the code points are properly sorted. - mathml/relations/css-styling/attribute-mapping-002.html: We cannot test with fraktur/double-struck anymore. Instead, rely on inheritance of text-transform on the parent. Note that mathvariant mapping is now only done for the <mi> element. -- wpt-commits: 08bac45e83cdf9980c00db1e94c0d385d0ca28c3 wpt-pr: 38490

NSoiffer added need polyfill need specification update needs-tests labels Dec 15, 2022

bkardell mentioned this issue Jan 25, 2023

MathML Core Meeting Jan 30, 2023 #185

Closed

fred-wang added a commit that referenced this issue Feb 13, 2023

Remove mathvariant from core (except 'normal')

4634157

#182

fred-wang mentioned this issue Feb 13, 2023

mathvariant digits mapping missing some cases in spec #109

Closed

dginev mentioned this issue Feb 13, 2023

[MathML] remove reliance on mathvariant brucemiller/LaTeXML#2051

Closed

fred-wang mentioned this issue Feb 14, 2023

Remove text-transform tests for math values, except math-auto web-platform-tests/wpt#38490

Merged

fred-wang added a commit that referenced this issue Feb 16, 2023

Make mathvariant a mi attribute only.

48f4759

#182

fred-wang mentioned this issue Feb 24, 2023

Make mathvariant a mi attribute only. #187

Merged

fred-wang added a commit that referenced this issue Feb 24, 2023

Make mathvariant a mi attribute only. (#187)

4dc3d57

#182

bkardell mentioned this issue Feb 24, 2023

MathML Core Meeting Feb 27, 2023 #189

Closed

bkardell closed this as completed Feb 27, 2023

runarberg mentioned this issue Apr 17, 2023

mathvariant is mostly depricated runarberg/mathup#70

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove mathvariant from core (except 'normal') #182

Remove mathvariant from core (except 'normal') #182

NSoiffer commented Dec 15, 2022 •

edited

Loading

dginev commented Dec 15, 2022

NSoiffer commented Dec 15, 2022

fred-wang commented Dec 16, 2022

fred-wang commented Feb 10, 2023

dginev commented Feb 10, 2023

fred-wang commented Feb 13, 2023

fred-wang commented Feb 14, 2023

fred-wang commented Feb 14, 2023

dginev commented Feb 14, 2023

NSoiffer commented Feb 14, 2023

davidcarlisle commented Feb 15, 2023

dginev commented Feb 16, 2023 •

edited

Loading

NSoiffer commented Feb 17, 2023

fred-wang commented Feb 24, 2023

bkardell commented Feb 27, 2023

Remove mathvariant from core (except 'normal') #182

Remove mathvariant from core (except 'normal') #182

Comments

NSoiffer commented Dec 15, 2022 • edited Loading

dginev commented Dec 15, 2022

NSoiffer commented Dec 15, 2022

fred-wang commented Dec 16, 2022

fred-wang commented Feb 10, 2023

dginev commented Feb 10, 2023

fred-wang commented Feb 13, 2023

fred-wang commented Feb 14, 2023

fred-wang commented Feb 14, 2023

dginev commented Feb 14, 2023

NSoiffer commented Feb 14, 2023

davidcarlisle commented Feb 15, 2023

dginev commented Feb 16, 2023 • edited Loading

NSoiffer commented Feb 17, 2023

fred-wang commented Feb 24, 2023

bkardell commented Feb 27, 2023

NSoiffer commented Dec 15, 2022 •

edited

Loading

dginev commented Feb 16, 2023 •

edited

Loading