Deprecate/Remove mathvariant attributes

[fred-wang]

I'm opening this for the record as that was discussed in previous meetings.

Basically, some people think this attribute is not very useful as one can just use the equivalent transformed unicode characters. It was designed a long time ago to work around issues with non-BMP characters.

Others mentioned that modern LaTeX engines just perform the character transform and only allow to use commands like \mathfrak for text (i.e. \mathfrak{a} but not \mathfrak{\frac{a}{b}}). (note: my version of XeLaTeX still seem to support \mathfrak{\frac{a}{b}}) so we could somewhat restrict mathvariant to token elements.

I suspect mathvariant is still quite popular in tools / existing content. Trying \mathfrak{\frac{a}{b}}) on LaTeXML, Mathoid/Wikipedia and TeXZilla, the first uses transformed characters, the second mathvariant on mi elements, the third mathvariant on mstyle element.

The consensus was to try to make it part of CSS's text-transform:
https://lists.w3.org/Archives/Public/public-mathml4/2019Mar/0007.html
See also #31 #1

[fred-wang]

First results from #55 suggest that mathvariant is still widely used, so I'm don't think we can remove it and browsers should still support it.

[physikerwelt]

First results from #55 suggest that mathvariant is still widely used, so I'm don't think we can remove it and browsers should still support it.

Most usage statistics are collections generated from converting TeX to MathML. I think, modifying the converters to output mathml4 instead of mathml3 has to be done anyhow... Thus I think, we should better ask ourselves how much effort would the change in the converter be, rather than how much is a particular element used.

[fred-wang]

I agree it is worthwhile to know how much effort it is to update the converter. However
(1) It's still useful to know if an element/attribute is actually used at all in real page, even when converters have capability to generate it.
(2) There are other uses than LaTeX to MathML converters (we need more stats for them!).
(3) Changing the converters will not necessarily automatically update existing content.

In the case of mathvariant, we have a converter like itex2MML (and its JS clone TeXZilla) which has been there for 20 years. It is a LALR parser generated by bison/flex tools, which makes it extremely fast (compared to other LaTeX to MathML converters) but since it generates the output stream bottom-up you cannot apply the mathvariant transform at the time you output the character. Maybe that can be fixed with some complete refactoring to generate a JSON structure instead of a string (fred-wang/TeXZilla#10) probably at the price of a performance loss. In any case, that does not solve the case of existing content.

For the browser implementation:
(1) mathvariant is very similar to CSS text-transform, so it shouldn't be a problem to implement it that way if the CSS WG accepts it.
(2) The automatic italic feature is necessary anyway, so we would still need to implement some character transformation, even if we remove mathvariant from core.

[dani31415]

A side effect of text-transform is that when copy and paste as plain text, the content should be the original one and not the transformed according to the CSS specification (w3c/csswg-drafts#627 (comment)). If this is okay, it seems reasonable to use, from my point of view, the text-transform.

[bkardell]

@dani31415 wellllllllll.... there is a lot here that is written down and a lot that works differently from what is written down and a lot that is being debated for various reasons, so I don't think that this is necessarily a given. See also for example w3c/csswg-drafts#3775, for one of the many open issues here.

[fred-wang]

Additional note: we still need mathvariant="normal" to cancel the automatic math italic behavior on single-char mi, so we won't be able to completely get rid of the mathvariant attribute anyway.

[fred-wang]

Current proposal:

1. New text-transform values for math, handled/discussed at the CSS WG.
2. This implies we should follow whatever the CSS/a11y/implementers decide regarding text copy / accessible tree of text-transforms ([css-text] text-transform's design, intent and reality resolution csswg-drafts#3775):

• Update the MathML spec accordingly regarding copy of the character. I believe, there is not any clear choice between copying the original or copying the transformed character. When copying the MathML tree, the mathvariant attribute is preserved anyway.
• Add a note for a11y, saying that it is expected enough information will be exposed to assistive technologies so that they can present the transformed text (hence we don't depend on what the CSS WG decides regarding the exposed character).

3. Keep mathvariant and automatic italic in MathML Core but specify a native implementation using text-transform:

• mi { text-transform: math-auto; }
• Map mathvariant value X to text-transform: math-X;

[fred-wang]

Resolution:

• https://lists.w3.org/Archives/Public/public-mathml4/2019Apr/0022.html
• Keep in core, mathvariant mapped to text-transform

Specification:

• N/A

Implementation:

• N/A

Polyfill:

• N/A

Tests:

• N/A