fred-wang commented 5 years ago

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 commented 5 years ago

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

Proposal and discussion should be moved to CSS WG github, even if it's still a draft.
Mathvariant should probably be integrated into text-transform.
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 commented 5 years ago

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 https://github.com/w3c/csswg-drafts/issues/3739

76 is not resolved.

fred-wang commented 5 years ago

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:

https://github.com/w3c/csswg-drafts/issues/3745 https://github.com/w3c/csswg-drafts/issues/3746

Let's see what the CSS WG people say.

rwlbuis commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

NSoiffer commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

w3c / mathml

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

76 is not resolved.