[css-fonts] Add new CSS properties math-script-level and math-style

[fred-wang]

cc @mrego @emilio @rwlbuis @bfgeek

This proposal introduces two new CSS properties math-style and math-script-level controlling how the font-size evolves inside mathematical constructions. More generally math-style may be used to indicate to implementations of math layout (e.g. MathML) whether logical height should be minimized. For details, see the explainer from the MathML Refresh CG repository.

Tentative tests:
https://w3c-test.org/css/css-fonts/math-script-level-and-math-style/
https://github.com/web-platform-tests/wpt/tree/master/css/css-fonts/math-script-level-and-math-style/
All the tests pass in Igalia's chromium-mathml build.

Drafts:
https://mathml-refresh.github.io/mathml-core/#the-math-style-property
https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property

[fred-wang]

Two quick comments on this:

• As mentioned in [css-text] Add new CSS text-transform values for math #3745 I've been confused and thought the CSS WG suggested to use function notation. The grammar for math-script-level in my initial proposal was auto | add <integer> | <integer>
• @bkardell pointed out that math-script-level is very similar to counters. Actually the only differences seem to be the special interaction with math-style (the "auto" value used for math fractions) and with font-size (use to scale down the text size in scripts etc). Maybe that similarity could help to implement the feature, by relying on some "reserved" counter name or something like that.

[AmeliaBR]

Since math-style is swapping between a block-like version and an inline version, would it make sense for it to have a default auto version that keys off the display value? (Specifically, the <display-outside> mode.)

That would still allow authors to set a different technique, and allow browsers to trigger that behavior based on MathML semantics, while doing the smart thing for general CSS layout.

Note that I think this would also change how the two properties interact by default.

[briansmith]

I think it would be useful to see an example of where math-style is necessary. It seems to me that styling things differently based on the math style can be done already in CSS, by using attribute selectors to determine what the math style should be, and using only CSS to decide which sizing/layout rules should be used.

Also, how would a CSS stylesheet access the Math OpenType features like scriptPercentScaleDown? I want to be able to write something like this (obviously oversimplified):

sup {
    /* Redefined to shift up by superscriptShiftUp when available. */
    vertical-align: super;

    /* A new syntax defined to be equal to scriptPercentScaleDown,
       interpreted as a percentage. */
    font-size: math-script;
}

sup sup, sub sup {
    /* A new syntax defined to be equal to scriptScriptPercentScaleDown,
       interpreted as a percentage. */
    font-size: math-script-script;
}

Reading the explainer, I get the impression that the proposal is written assuming a different model for CSS styling of math that doesn't allow for these kinds of things. It would be good to see the overall architecture of the design explained somewhere to understand all these proposals.

[fred-wang]

@briansmith The proposal is based on MathML 3's model (corresponding to displaystyle and scriptlevel attributes), Microsoft's OpenType MATH table and current Mozilla's CSS-based implementation. It has been discussed in length during one MathML Core meeting, trying to remove things that don't align with CSS and we reached this consensus (thanks to @emilio for helping on simplification!).

The browsers' CSS engine code don't know about the DOM so they really need the values of math-script-level and math-style as CSS properties in order to calculate the computed value of the font-size. Additionally, math-style is used in several other places of the layout classes and from Firefox/WebKit's experience, CSS resolution is more reliable than implementing our own inheritance model in MathML classes.

As indicated in the explainer / MathML3, MathML's model (and hence this proposal) is a generalization of TeX: "These properties can be used to emulate TeX’s \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle modes, they correspond to math-style and math-script-level as “display” and 0, “inline” and 0, “inline” and 1, and inline and 2, respectively. These are important use cases requested by math people.". So you can already get what you want by setting math-style and math-script-level appropriately.

[briansmith]

@fred-wang I understand all of that. However, this seems to assume that there is going to be a lot of logic specific to math within the internals of the layout engine, as opposed to having that logic within the MathML UA stylesheet. it seems like the plan is to have C++ code look at the math-style property and then change how font-size is interpreted, right? Why can't we avoid that C++ code? In particular, it would be useful to see an example where the MathML stylesheet can't achieve the same effects using [displaystyle] attribute selectors.

It seems to me that the reason is that not enough functionality is exposed to CSS to enable that to happen. But then, why expose math-style instead of the more fundamental building blocks that would enable more of the logic to be done in CSS? In particular, in the explainer there is an algorithm proposed for calculating the computed font-size ("...defined recursively as follows..."). I think it would be good for that algorithm to be implemented in the MathML CSS stylesheet instead of in C++ code in the rendering engine.

[litherum]

Should we be creating a new [css-math] spec for all of these new math proposals? I would imagine that most implementors would want to implement these properties together, and that is more difficult if the properties are spread across many specs. I'm not sure how useful a single one of these is without all of its sibling math properties.

[briansmith]

@litherum If there were to be a [css-math] then I think that would encourage adding math-specific features to CSS, instead of encouraging the adding of more general features that math and non-math applications can use.

I'm not sure how useful a single one of these is without all of its sibling math properties.

If there were motivating test cases, then it would be easier to see how things would interact and explore alternatives. For example, it would be useful to have examples for a^b^c, a^b^c^d, a_(b_c), a_(b_(c_d), a_(b_c)^(d^e), a_(b_(c_d))^(e^f) and similar in both inline and display contexts to evaluate how the proposed algorithm works. In these cases in particular I think users would sometimes like to override the default sizing algorithm to implement TeX-like two-level sizing or similar, and I think it would be useful to see how the proposal allows users to do that too, given these examples. (Allowing users to easily fine-tune the layout is one reason I suggest doing more of the layout in the default HTML/MathML CSS stylesheet instead of in the layout engine itself.)

[fred-wang]

Should we be creating a new [css-math] spec for all of these new math proposals? I would imagine that most implementors would want to implement these properties together, and that is more difficult if the properties are spread across many specs. I'm not sure how useful a single one of these is without all of its sibling math properties.

Currently the only proposal are mathvariant (more text-transform values) and math-style/math-script-level (interacts with font-size) so it makes sense to have them in the corresponding specs. The idea is to progressively propose small and independent bits in order to facilitate acceptance by the CSS WG, implementation and testing. And believe me, they are definitely useful to improve/simplify current MathML implementation.

[fred-wang]

Testcase related to #3906 :

<math style="font-size: xx-large; font-family: serif">
  <mstyle style="font-family: monospace;">
    <mtext>level 0</mtext>
  </mstyle>
  <mstyle scriptsizemultiplier="0.71" scriptminsize="0pt" scriptlevel="1"
          style="math-script-level: 1; font-family: monospace;">
    <mtext>level 1</mtext>
  </mstyle>
</math>
<script>
  var mstyle = document.getElementsByTagName("mstyle");
  for (var i = 0; i < mstyle.length; i++)
    console.log(`${mstyle[i].firstElementChild.innerHTML}: ${getComputedStyle(mstyle[i]).fontSize}`);
</script>

@emilio @rwlbuis The resolved values I get are 26px and 26px * 0.71 = 18.46px in Igalia's chromium-mathml build ; but 26px and 22.7167px in Firefox.

[css-meeting-bot]

The CSS Working Group just discussed math-script-level and math-style.

The full IRC log of that discussion

<TabAtkins> Topic: math-script-level and math-style
<astearns> github: https://github.com//issues/3746
<TabAtkins> bkardell_: In doing Chromium impl of mathml, and trying to explain the mathml magic in a way that's part of the platform, there are some funky areas
<TabAtkins> bkardell_: So we want to get that funky added to CSS.
<AmeliaBR> Explainer link: https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-explainer.html
<TabAtkins> bkardell_: One is math-style. As part of layout, takes into consideration whether your math equation is happening inline in text or as a block; aligns baselines differently and tries to minimize vertical size in inline, etc.
<TabAtkins> bkardell_: If we have that, this is one more thing that becomes a UA stylesheet rule.
<TabAtkins> bkardell_: math-script-level is in my mind a lot like counters. It lets you scale up or down font-size
<TabAtkins> emilio: So when you nest an element that's a subscript or superscript, or part of a fraction, the font-size shrinks.
<TabAtkins> emilio: But in CSS it affects the computed font-size, which is annoying.
<TabAtkins> fantasai: This effects the font-size. Why is it called script-level, and why is separate from font-size?
<TabAtkins> bkardell_: This is how I think it's similar to counters, it carries info about nesting.
<TabAtkins> AmeliaBR: So elika's question is why not do this with relative font sizes. I think reason is to give browsers some more flexibility...
<TabAtkins> fantasai: We can have math-larger and math-smaller...
<TabAtkins> fremy: If you have a fraction, 1/2. You can nest, 1/(1/2). But third level of nesting, switch to a side-by-side fraction.
<TabAtkins> bkardell_: Even within that context, you can have sub/superscripts too.
<TabAtkins> AmeliaBR: There definitely needs to be a new property. Math fonts have a property saying how much you scale down as you go down a script level.
<TabAtkins> AmeliaBR: Do you need to be able to absolutely set "3 sizes down from normal", or is it always single steps?
<TabAtkins> bkardell_: These map stragiht from MathML attributes. I know the name isn't great, but
<myles_> q+
<TabAtkins> emilio: Figuring out which nodes need to incrmeent or decrement the script level is pretty tricky
<AmeliaBR> `font-size-math-adjust`???
<TabAtkins> emilio: It would be good to see if we can decouple the script-level from font-size, because it becomes much easier, add an "auto" value and figure it out doing layout or something
<TabAtkins> AmeliaBR: Does nesting level have effects other than font-size?
<TabAtkins> myles_: bkardell said yes
<una> what about `font-size-math-adjust: <nesting-level>`
<TabAtkins> fantasai: So then you'd want to *select* based on that level. So then that info must be in the DOM.
<TabAtkins> fantasai: We've had similar cases in the past of things thought to be in CSS that we pushed back and said "no, this needs to be in the DOM".
<TabAtkins> fantasai: Like directionality.
<myles_> s/bkardell said yes/fremy said yes/
<astearns> ack myles_
<astearns> q+ myles_
<fremy> (yep, for the record I agree with fantasai)
<TabAtkins> dbaron: I think one of the reasons for this is that mathml has attributes that specify both the ratio of font-size for each change in script level, and the min font-size at which you stop changing it.
<TabAtkins> dbaron: script-size-multiplier and script-min-size
<TabAtkins> fantasai: Does this mean we're adding font-min-size back?
<TabAtkins> myles_: There have been a half-dozen or so of these proposals. How do these affect existing elements outside of MathML?
<TabAtkins> bkardell_: Some people do indeed think that <math> isn't great, and math layout should be a normal part of CSS.
<una> `font-size-math-adjust: <max-nesting-level> / <min-font-size>`
<TabAtkins> florian: I think we want the building blocks of math in normal CSS. And I've heard the argument that MathML is bad for math; mathjax people will do that.
<TabAtkins> florian: So mathjax renders math into HTML or SVG, but they're missing some tools that make it subpar.
<TabAtkins> myles_: So what's the criteria here: hsould math layout be dumped in whole-hog?
<chris> https://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle.attrs
<TabAtkins> bkardell_: We're trying to find the mathml core and eliminate as much as possible.
<TabAtkins> bkardell_: So far we've been doing good at that.
<TabAtkins> bkardell_: Reusing CSS stuff well.
<chris> also https://www.w3.org/TR/MathML3/chapter3.html#presm.scriptlevel
<TabAtkins> astearns: I hear this as a request from another group, like the timed text people, to get something that they can't currently do in CSS.
<tantek> q?
<fantasai> TabAtkins: Is the goal that you can implement math layout with <div>s, or are we still using mathml but ...
<TabAtkins> dbaron: There are two different groups in w3c working on diff solutions here
<TabAtkins> s/are we still using mathml but .../are we saying that mathml is a special layout form, like SVG, that can have its own specialized CSS without influencing arbitrary text layout/
<TabAtkins> myles_: So if this is a generic layout mechanism, you need to be able to put flexbox inside of it
<TabAtkins> florian: I don't think we want to be able to take naive markup and get good math out of it.
<fantasai> TabAtkins: Are we intending that you can make a fraction, and the nuerator is a flexbox?
<iank_> q+
<astearns> ack myles_
<fantasai> TabAtkins: If so, you can nest flexbox into it. If not, then you can't.
<fantasai> TabAtkins: But need to know which way we're going so we can figure out how to interact with it
<fantasai> chrisl: ...
<fantasai> TabAtkins: We'd make a Math layout spec
<TabAtkins> iank_: So basically mathml is already in this state where you can nest CSS layout inside of it
<TabAtkins> iank_: And it uses CSS layouts to ahcieve some of its layouts
<TabAtkins> iank_: so <mtable> uses css tables
<TabAtkins> iank_: The text inside of mathml is just text layout, it can do floats/etc
<tantek> q?
<TabAtkins> iank_: This was the feedback we gave to the group: you need to define how this interacts with all of CSS.
<astearns> ack iank_
<tantek> q+
<TabAtkins> myles_: ARe you saying that philophically that's how this shoudl be designed, or that it's just a quirk of impl.
<TabAtkins> Rossen: So support rich layout that allows math, and interacts nicely with the rest of css.
<fremy> q+
<astearns> ack tantek
<TabAtkins> astearns: A detail is that some requirements, we may not get to. LIke western typography, some details we never get to.
<TabAtkins> myles_: So the intention is that we end up with display:math at some point?
<TabAtkins> AmeliaBR: display:fraction, perhaps, like display:ruby : some specialized focused layouts as necessary
<dauwhe> this is a w3c strategy funnel issue https://github.com/w3c/strategy/issues/43
<myles> q+
<tantek> q-
<astearns> ack fremy
<TabAtkins> fremy: So math-level.
<TabAtkins> fremy: If you want a layout that's different depending on the math level, that's fine. We could do that.
<dauwhe> https://www.w3.org/community/knowledge-domain/
<TabAtkins> fremy: But the way I see this is that math-level is changing other properties, in some weird interaction.
<astearns> q+
<TabAtkins> fremy: So my mental model matches fantasai, this is at the DOM level.
<TabAtkins> fremy: And if we go the "you should do math using divs", that doesn't work.
<TabAtkins> fremy: My impression from when I worked on this, is that this is complex to put in a CSS property.
<florian> q+
<TabAtkins> fremy: But if our goal is to allow everything in CSS, I don't see how it's a markup thing.
<TabAtkins> fremy: So question is we need mathml markup, or is there a simplified markup that would provide the grouping/level/etc that we could provide the levels on top of.
<astearns> ack myles
<TabAtkins> myles: So let's say we do wanna go on this path where we induct math layout into CSS.
<TabAtkins> myles: When we write CSS specs we have to describe layout exactly.
<TabAtkins> myles: Do you envision that this group would make those decisions, or that MathML would do it and deliver them to us and we'd put them into our docs?
<TabAtkins> bkardell_: Right now they're trying to get that defined.
<TabAtkins> bkardell_: Huge criticism right now is that it's super underdefined.
<TabAtkins> iank_: As part of our launch process we require interop-capable specification.
<tantek> FYI: https://caniuse.com/mathml
<TabAtkins> iank_: And the two impls currently aren't remotely interoperable, especially layout.
<TabAtkins> iank_: I spent two or three hours one day and created a list of issues where Firefox and WebKit differ.
<florian> q?
<TabAtkins> fantasai: If mathml is going to define a layout model closer to css, they should def interact with us more than what's happening currently.
<TabAtkins> fantasai: So we can make sure it's compatible with css layout and all the interactions with othe rproeprties.
<tantek> Is there an opportunity for CSS/MathML joint meeting at TPAC?
<TabAtkins> fantasai: Just because of where the expertise lies.
<AmeliaBR> q+
<Rossen_> q?
<TabAtkins> astearns: I would really like to see more stuff in the explainer. Righ tnow it looks like a reiteration fo the proposal. It has some markup examples without intended renderings, etc.
<Rossen_> ack astearns
<TabAtkins> fantasai: SAme, I don't really understand what it's trying to do currently. So I can't even comment on whether they're doing it right or not.
<TabAtkins> fantasai: So somebody came up with a solution to a problem, but I don't udnerstand the problem, or why this is the best solution to that problem.
<TabAtkins> fantasai: Would love to advise them, but can't right now.
<astearns> ack florian
<TabAtkins> florian: Back to fremy's point, for those trying to solve math with css, i don't think the goal is markup that resembles mathml and uses display:fraction, display:sqrt, etc. I think it was to start from a mathml-ish markup that is processed into a pile of divs, then rendering fractions with a vertical flexbox, etc. Only a few lacking aspects would need to be added.
<TabAtkins> fremy: I don't disagree, that's also an option. But if that's the goal then you don't need the math-script-level property.
<TabAtkins> myles: Agree. We already have SVG then.
<astearns> ack AmeliaBR
<TabAtkins> TabAtkins: SVG doesn't quite solve it - we still need a few small things, like baseline control, stretchy characters. Talked about this at last TPAC. But it's pretty minimal.
<TabAtkins> AmeliaBR: So wrapping up, we have some requests from Brian's team at Igalia about how we want communication to happen, better explainers. larger comprehensive use-cases, rather than one proposal at a time.
<TabAtkins> AmeliaBR: Would be useful if this group gave feedback about how we'd like to be communicated with.
<TabAtkins> AmeliaBR: And then there's further concern about where things should live, CSS vs DOM, etc.
<astearns> ack dbaron
<AmeliaBR> s/requests from/requests for/
<TabAtkins> dbaron: elika was asking about the problem to be solved. There is a political disagreement about the problem.
<TabAtkins> dbaron: In that, there is the question of whether mathml is the way forward.
<TabAtkins> dbaron: A few years ago when it was in Firefox only and we thought we might remove it, everyone thought MathML wasn't the right way to do it; do it in CSS instead, etc.
<TabAtkins> dbaron: And add to CSS to improve mathjax output.
<TabAtkins> dbaron: Now we're somewhat surprisingly getting to a world where mathml is supported across browser engines.
<TabAtkins> dbaron: So question is whether mathml is, like html, something that needs CSS to reflect on things in it.
<TabAtkins> dbaron: ARe we concerned with MathML backcompat such that CSS needs to care about its legacy mechanisms.
<TabAtkins> dbaron: Or do we have substantial flexibility to change things as necessary.
<TabAtkins> dbaron: So three possibilities:
<TabAtkins> dbaron: 1. MathML is in browser engines, CSS has to be compatible with that.
<TabAtkins> dbaron: 2. MathML is in browser engines, but we might make substantial changes in the process and can adjust it to CSS better.
<TabAtkins> dbaron: 3. MathML isn't the right path forward, and math should be taking this up the path.
<TabAtkins> dbaron: Path to making this decision right now is very uncoordinated and not based on principles, but rather on lots of small decisions where people might not be aware of the larger path they're supporting.
<TabAtkins> dbaron: Possible we should be discussing this more epxlicitly.
<TabAtkins> dbaron: I think before we decide waht we're trying to solve, we might want to have that discussion.
<TabAtkins> bkardell_: Before I went to Igalia, I spent a lot of time thinking about this.
<TabAtkins> bkardell_: My own thought were between 2 and 3.
<TabAtkins> bkardell_: HTML isn't very perfect semantically either, it's focused on text.
<TabAtkins> bkardell_: So it has no starting point. It's not like SVG, where we all agree what SVG is.
<TabAtkins> bkardell_: Thirty years the community has been working on something, lots of back and forth.
<TabAtkins> bkardell_: When we got to HTML5 and mathml was codified into the parser, now it's in a special weird place.
<TabAtkins> bkardell_: If there's something I'd personally advocate, it's that we need to find a starting point or we can't have this convo.
<TabAtkins> bkardell_: So back with corp hat on, the core-math group is trying to find the minimal bits that hold things together.
<TabAtkins> bkardell_: I don't want to personally be like "mathml is the best thing ever", I dunno. I want to be malleable here.
<TabAtkins> <br dur=20min>
<TabAtkins> myles_: Minutes of the Math session during last year's tpac: https://lists.w3.org/Archives/Public/www-style/2018Nov/0008.html

[fred-wang]

dbaron: I think one of the reasons for this is that mathml has attributes that specify both the ratio of font-size for each change in script level, and the min font-size at which you stop changing it.
fantasai: Does this mean we're adding font-min-size back?

The MathML Refresh CG had decided to remove the MathML scriptminsize and scriptmultiplier attributes, that's why these are not included in the proposal (we still need to remove them from Gecko). The former is better configured elsewhere (outside of the MathML world) while for the latter we rely on the factors specified in the OpenType MATH table.

The MathML Refresh CG had a11y concerns regarding the font size, because it can scale down very fast in very nested math expressions. Hence we need a minimum limit to keep the text readable. @emilio had suggested to rely on the font-min-size property for that purpose. However, It's fine if you remove it, as long as browsers have some global configuration to set a minimum value for the used font-size.

I removed the comment regarding font-min-size and font-max-size from the proposal, since that's no longer a concern.

[fred-wang]

Tests also updated: web-platform-tests/wpt#17228

[tabatkins]

Summarizing some important parts of the minutes:

---

The core question here is exactly what the intention is for "supporting MathML" to look like. There appears to be broadly three possible approaches:

1. MathML is its own unique thing, a la SVG, and CSS adapts to support whatever it happens to need.
2. MathML leans mostly on CSS to explain itself, with layout algorithms for custom MathML stuff being described in CSS-compatible ways. (For example, defining a display: math-fraction; layout.) In other words, we expect that you could take the MathML markup structure, replace it with divs, apply a good chunk of math-specific styling, and get good layout.
3. We figure out how to squeeze CSS into producing math layout, even if that requires a pile of divs to implement properly. Whatever minimal additional powers are needed are added to CSS, but we mostly rely on existing CSS (such as using a vertical flexbox to layout fractions, etc). MathML elements get described in terms of anonymous boxes approximating the pile-of-divs markup structure needed for arbitrary math layout to get the same effect.

1 is the most disruptive and "magic" method; it means that MathML is the only way to do math layout, and any new math layout primitives must be designed by adding to MathML, like SVG is today.

2 is less magic, but still requires a pile of work from both MathML and CSS people, and new types of math layout require adding to CSS.

3 is the least magic, and most supportive of community-driven additions; it's closest to the Extensible Web Manifesto ideals, tho the end result is a bit nastier in the markup. But tooling can generally hide that from us. It's also the least amount of new work, as we're reusing the existing platform as much as possible.

---

The relevance here is that if we go with 3, then this property doesn't make any sense. The effect of the level on the layout is implemented just by outputting different DOM and/or styles. It's only in 1 and 2 that this property would be useful. So we need to decide which strategy we're going with.

(I favor 3.)

[frivoal]

For completeness's sake, there's also (4), which is like 3, except that mathml element don't get described in terms of a pile a divs, they get converted into a pile of diffs by some preprocessing tool, and we just don't ship mathml to the front end. I think that this is distinct from (3) as you described it, but in that case too, the property proposed here is not meaningful.

(I am not sufficiently informed about what's practical and what works well to confidently say which of the 4 I favor)

[tabatkins]

Sure. I left that out because that's effectively just not shipping mathml at all. But yeah, that's a valid outcome. (And what you'd get when you want to innovate in math display ahead of standardizing a new MathML thing.)

[fred-wang]

Closing this, since it is handled in #5389 and #5387