New properties for CSS math-variant, script-level and math-style

[fred-wang]

The current proposal is
https://mathml-refresh.github.io/mathml-css-proposals/ but there is currently a lot to discuss!

It's related also to the simplification of mstyle #1 so that it can just become pure CSS inheritance.

Please make sure to read the comments, as that might require some simplification of MathML too:
https://mathml-refresh.github.io/mathml-css-proposals/math-variant-comments.html
https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-comments.html

cc @mrego

[fred-wang]

Just for the record, some feedback from the CSS WG was:

1. Proposal and discussion should be moved to CSS WG github, even if it's still a draft.
2. Mathvariant should probably be integrated into text-transform.
3. People were considering the syntax "text-transform: math(fraktur);" . It seems this parenthesis syntax is becoming more and more popular.

(cc' @rego @rwbuis)

[fred-wang]

cc @rwlbuis @emilio

After yesterday's meeting I think we are close to be able to move this to the CSS WG. Proposal is to modify https://github.com/mathml-refresh/mathml-css-proposals/blob/master/math-script-level-and-math-style-explainer.md#css-math-script-level-property as follows:

• Use the OpenType MATH parameters for the scale factor ( https://github.com/mathml-refresh/mathml-css-proposals/blob/master/math-script-level-and-math-style-comments.md#opentype-math-values-scriptpercentscaledown-and-scriptscriptpercentscaledown )
• Be more explicit about the fact that math-script-level does not affect font-size when the latter is specified.
• Mention that font-min-size (and font-max-size) clamping happens after the change due to math-script-level. This would be implied by [css-fonts] consider not making font-min-size and font-max-size affect font-size computed value csswg-drafts#3739

#76 is not resolved.

[fred-wang]

As @NSoiffer we should probably not spend too much time on the CSS details. I've modified the CSS proposals after the previous discussion/feedback and I've moved the proposals to csswg-drafts:

w3c/csswg-drafts#3745
w3c/csswg-drafts#3746

Let's see what the CSS WG people say.

[rwlbuis]

We implemented script-level as math-script-level as described here:
https://github.com/mathml-refresh/mathml-css-proposals/blob/master/math-script-level-and-math-style-explainer.md#native-implementations-of-display-displaystyle-and-scriptlevel

It turns out that exact timing of when to handle is hard when done in C++, by the time we can handle math-script-level the computed font size is pretty much determined already and hard to change anymore. Because of this for now we opted for a user agent stylesheet solution.

[rwlbuis]

To get fractions right we add such a rule (verbose because universal selector is not allowed in UA):
mfrac > maction, mfrac > menclose, mfrac > merror, mfrac > mfenced, mfrac > mfrac, mfrac > mpadded, mfrac > mphantom, mfrac > mroot, mfrac > msqrt, mfrac > mrow, mfrac > mspace, mfrac > mstyle,
mfrac > mn, mfrac > mtext, mfrac > mi, mfrac > ms, mfrac > mo, mfrac > munder, mfrac > mover, mfrac > munderover, mfrac > msub, mfrac > msup, mfrac > msubsup, mfrac > mmultiscripts, mfrac > semantics {
math-script-level: auto;
math-style: inline;
}

[rwlbuis]

To get roots right we add such a rule (verbose because universal selector is not allowed in UA):
mroot > maction:nth-child(n+2), mroot > menclose:nth-child(n+2), mroot > merror:nth-child(n+2), mroot > mfenced:nth-child(n+2), mroot > mfrac:nth-child(n+2), mroot > mpadded:nth-child(n+2), mroot > mphantom:nth-child(n+2), mroot > mroot:nth-child(n+2), mroot > msqrt:nth-child(n+2), mroot > mrow:nth-child(n+2), mroot > mspace:nth-child(n+2), mroot > mstyle:nth-child(n+2),
mroot > mn:nth-child(n+2), mroot > mtext:nth-child(n+2), mroot > mi:nth-child(n+2), mroot > ms:nth-child(n+2), mroot > mo:nth-child(n+2), mroot > munder:nth-child(n+2), mroot > mover:nth-child(n+2), mroot > munderover:nth-child(n+2), mroot > msub:nth-child(n+2), mroot > msup:nth-child(n+2), mroot > msubsup:nth-child(n+2), mroot > mmultiscripts:nth-child(n+2), mroot > semantics:nth-child(n+2) {
math-script-level: add(2);
math-style: inline;
}

[rwlbuis]

To get script-level right for script elements, we specify all possible combinations with children (using :nth-child(n+2) to select them) and apply to them:
math-script-level: add(1);
math-style: inline;

[rwlbuis]

math-style probably works but needs more testing, since focus was on math-script-level.

[NSoiffer]

For the mfrac rules, what does auto do? The rule should be:

The element sets displaystyle to "false", or if it was already false increments scriptlevel by 1, within numerator and denominator.

Easy to do in code, but maybe not with CSS because you can't condition the selector on a CSS value, right?

[rwlbuis]

For the mfrac rules, what does auto do? The rule should be:

The element sets displaystyle to "false", or if it was already false increments scriptlevel by 1, within numerator and denominator.

Easy to do in code, but maybe not with CSS because you can't condition the selector on a CSS value, right?

Right, the auto behavior has to be done in code, actual commit is here to give you an idea:
https://github.com/Igalia/chromium-dev/commit/a8aafff1ff1fbdac54a35f006b19bd8efbeaa982

[fred-wang]

Resolution:

• We agreed to go ahead and continue discussion at the CSS WG.

Specification:

• Define the mapping in MathML Core.
• Need to update a bit the CSS proposal after Chromium's implementation.

Implementation:

• WebKit: TODO
• Firefox: TODO
• Implemented in Chromium.

Polyfill:

• N/A

Tests:

• ¡¡¡¡A lot of tests!!!!
• They should probably be located in the css/ directory and have the "tentative.html" extensions for now.

[fred-wang]

Removing "need tests" since they are at:
https://w3c-test.org/css/css-text/text-transform/math/
https://w3c-test.org/css/css-fonts/math-script-level-and-math-style/

[fred-wang]

It seems "internal" properties are supported in WebKit:

https://lists.webkit.org/pipermail/webkit-dev/2019-September/030770.html

and that's the case in Gecko and Blink too.

So we probably don't need to push too much for this at the CSSWG and just implement things internally for the sake of native MathML support. If later users ask for it, it would be easy to expose them for implementers and we would have concrete use cases we can show to the CSSWG.

Incidentally, one of the use case I was thinking about is if people write a fancy custom MathML layout (e.g. attaching scripts to each side / corner of a base) involving math-style and script-level then they would need to have these properties exposed. But for now math "polyfills" don't rely on modern techniques like custom elements or CSS layout API so this is highly hypothetical.

[fred-wang]

As proposed during the hackfest, we can close it and open individual issues as necessary.