Create display values for the special types of layout algorithms that MathML uses.

[bfgeek]

My preference here is that MathML becomes less special.

Basically:

• MathML elements must get their layout type from the display value.
• MathML elements must accept all possible other CSS display values.

This needs tests, and if any box-tree fixups are required.

This is similar to how tables work today.

[fred-wang]

cc @rwlbuis

[fred-wang]

For now we have:

Tables:
https://mathml-refresh.github.io/mathml-core/#table-or-matrix-mtable

Token w3c/mathml-core#139:
https://mathml-refresh.github.io/mathml-core/#layout-of-mtext
https://mathml-refresh.github.io/mathml-core/#layout-of-operators
https://mathml-refresh.github.io/mathml-core/#space-mspace

Mrow-like: #53
#53
https://mathml-refresh.github.io/mathml-core/#adjust-space-around-content-mpadded
https://mathml-refresh.github.io/mathml-core/#enclose-expression-inside-notation-menclose

Stack-like #54:
https://mathml-refresh.github.io/mathml-core/#fractions-mfrac
https://mathml-refresh.github.io/mathml-core/#underscripts-and-overscripts-munder-mover-munderover

Radical:
https://mathml-refresh.github.io/mathml-core/#radicals-msqrt-mroot

Scripts:
https://mathml-refresh.github.io/mathml-core/#subscripts-and-superscripts-msub-msup-msubsup

I'm assuming that we could merge munder/mover/munderover into one display if we add special handling for empty script and do box fix-up to always have three children. Similarly, I assume msub/msup/msubsup/mmultiscripts could be merged in one display type. And msqrt/mroot into one.

I wonder if menclose/mpadded could just be mrow with more powerful css properties or just removed and polyfilled instead (see #105 #103).

For token elements, it seems mo/mtext/mspace are just display: block with some special handling.

So my estimate would be 6 new display values (token, mrow, mfrac, underover, radical, scripts) maybe a few more depending on how we handle things.

[fred-wang]

Currently, most MathML elements have undefined display values. It is not clear how the layout is determined, although it is implicitly from the tag name. This is causing various issues for implementation purposes. Even in the specification, it is not clear how to revert the default "display: none" on annotations:

https://mathml-refresh.github.io/mathml-core/#semantics-and-presentation

For users, the most serious issue is that it is not possible to override existing layout of MathML tags with their own custom layout. For example to implement #29 we want to be able to do something like this using the CSS layout API:

mfrac[bevelled] {
    display: layout(slash);
}
<mfrac bevelled="true">
  <mn>1</mn>
  <mn>2</mn>
</mfrac>

(IIUC our rule of thumb was that if we remove features from MathML Core we should also add MathML IDL / shadowDOM / custom element / CSS layout APIs stuff at the same time so that people can write their own extensions)

A simple proposal to address this issue is the following: Introduce a new "display: mathml" (one can bikeshed on the names... "math" or "math-auto" etc) that would be the default for most elements. Elements with this value would determine their layout according to the tag name, fallbacking to a reasonable default (e.g. mrow layout for MathML elements and inline for non-MathML elements). That way users can override the default layout and we only need to propose a single css display value to the CSSWG. Details about would have to be specified later when we do more testing / implementation work.

---

The second use case is when someone wants to use math layout on non-MathML elements:

<div style="display: fraction">
  <div>1</div>
  <div>2</div>
</div>

MathML currently relies a lot on tag name (e.g. for embellished operators or to distinguish very similar but different script layout) and properties (e.g. scriptlevel & displaystyle) and elements interact together. So I feel we would either need to simplify MathML and/or introduce many new CSS display values & properties too to propose a full math layout support equivalent to MathML. If the goal is just to add basic math layout, it can already done with flexbox or similar.

Adding many properties and values is likely to be much harder to push at the CSSWG (even #31 seems difficult) so the proposal is not to do it for now. In that's needed in the future, we could still progressively expose the internal MathML layout algorithm.

[fred-wang]

Consensus from 2019/09/12: We agreed to go with one display: math value for now and I've updated the spec accordingly. @rwlbuis has already experimented the approach in chromium.

[NSoiffer]

Don't really need a test since test for fractions, etc., will cover the display