[css-display] display: math might not want to do magical box construction based on the kind of element it applies to

[emilio]

Instead, there should probably be different display values for each kind of box.

This was raised by @MatsPalmgren on #5385, but I think it deserves its own separate issue.

[astearns]

I assume this is the context?

@fred-wang wrote:

MathML layout is much more complex and there are too many tag-based rules inherited from MathML3 ; we are not proposing to introduce a new display for each MathML tag

There are only a dozen or so MathML-specific box types in Gecko, so I don't think that's a problem. CSS display can easily handle a dozen more math-* keywords if we need them. Some elements like <mtable>, <mtr>, <mtd> can use already existing table values.

I discussed this with @emilio and we don't like that display: math should magically compute to different values based on the tag name or that it should magically create different box types for math based on the tag name. If we want to express MathML box construction in CSS then it should follow normal CSS rules and not have special MathML hacks for how property values are computed and applied. Hacks like that only make CSS harder to implement, spec and teach to authors.

Fwiw, here's the MathML-specific box types that Gecko implements (besides math/block math): token, mrow, mo, mfrac, mmultiscripts, munderover, mpadded, mspace, msqrt, mroot, maction, menclose, semantics. (I don't know how well these match MathML Core. Maybe some could be merged if they are reasonably close in their layout?)

Anyway, we would prefer to keep display values having consistent behavior, i.e. that the value alone determines the box type to create, so we propose to add math-token, math-mrow etc for the box types that MathML needs. These values would have similar behavior as the existing Layout-internal values. This is a simpler model that can be reasoned about.

Originally posted by @MatsPalmgren in #5385 (comment)

[bkardell]

This seems reasonable and I think that both WebKit and our original take in blink also had a similarly small number of moving parts. I guess there's additional details to go into that for specifying things like how an mfrac works if there are the wrong number of children... Many things were discussed in the CG getting to here and an effort to draw the right, most necessary circles around the problems to get to "Level 1". I'm not sure how strongly people feel about whether it is necessary to get all of this in one leap?

(Note also that things here are currently (as of right now, I mean) in a bit of a strange place as there is a charter for a MathML WG submitted and has gone through initial reviews but still hasn't been presented to ACs yet. )

[css-meeting-bot]

The CSS Working Group just discussed MathML individual display types, and agreed to the following:

• RESOLVED: We are interested in defining all the math display types necessary for mathml layout

The full IRC log of that discussion

<fantasai> Topic: MathML individual display types
<fantasai> github: https://github.com//issues/5866
<dael> iank_: I would like to ask people more familiat with MathML
<fantasai> earlier discussion in https://www.w3.org/2021/04/14-css-irc
<dael> iank_: Does seem like consensus in this group
<dael> astearns: Dim recolection is mathML asked for the display types and we thought it too many
<dael> iank_: My recolection too.
<fantasai> s/we/Igalia folks/
<dael> astearns: Math WG just spun up. Maybe we can ping them on this
<fantasai> s/recolection/recollection/
<dael> astearns: I'll take an action to send this along
<dael> plinss: I'm in favor of more display types. Maybe not 100, but 2 or 3 with other properties to control sub-behaviors. Early disgn philosophy in Gecko. I don't want layout and design tied to semantics. I want it all in css
<dael> iank_: Quite probably quite a few, 5 or 6. Makes sense b/c distinct layout algos.
<dael> florian: Are these things only useful in context of math? Or are they potentially useful in general? In favor either
<bradk> These would be display-inside?
<dael> plinss: If we give tools people will have create ways to use them. People will find fun ways to display content we didn't dream of
<dael> iank_: mtable has display:table and display:tablecell so this normalizes to that behavior.
<fantasai> bradk, some of them might be more like internal table display types, have to check
<dael> iank_: display:mrow there might be. We should give that power
<florian> +1
<dael> emilio: Agree. If we want to style math with css using display ew have to do all or none. SVG does no such thing, it's its own box type. I like the direction of exposing all mathml display types
<dael> astearns: This will go into issue. I'll ping the new math WG and come back
<bradk> @fantasai I see. Thanks
<dael> fantasai: I'd like to propse we take a resolution. csswg believes this is the right direction to go and we prop that to math wg. Useful to capture we're on the same page
<dael> astearns: Unless anybody has reservations?
<dael> astearns: Prop: We are interested in defining all the math display types necessary for mathml layout
<dael> astearns: as individual display types or separate properties in css that let us control the variations
<dael> RESOLVED: We are interested in defining all the math display types necessary for mathml layout

[astearns]

@bert-github @NSoiffer could the new Math Working Group give us a definitive list of what display types we should add?

[fred-wang]

We've discussed about this issue during the MathML breakout session of the web engines hackfest and I'm trying to provide a summary below (@emilio and @drott feel free to complete or correct).

Historically, MathML was more like SVG (layout is tag-based) but there can be a motivation to make it more HTML-like (layout based on CSS display values). We started this by providing this display-inside value called "math". When that value is used (default for MathML elements) we still rely on tag names to decide the actual layout. However, this now gives a chance for authors to override it, for example with existing layout like grid or even custom defined via the CSS custom layout API. This seems interesting for people willing to write polyfills or to extend MathML Core with new layout, a use case initially suggested by @bfgeek. However during the conversation, it was not clear whether there is a strong use case for introducing more values?

Now regarding the actual values we could probably introduce one display for each of the 31 tags if we really want that. On the one hand that's probably too much (there are many duplicates e.g. mrow-based) and on the other hand that can even not be enough for existing implementations (e.g. WebKit & Gecko still use legacy layout from MathML3). It is also probably better to have something like "one display for each layout algorithm" but there are subtle aspects to consider. For example, the three elements msub/msup/msubsup have similar layout but still slightly different rules, which may require introducing new CSS properties instead. Other elements like mprescripts don't have any specific layout but may actually affect the algorithms of their parent (mmultipscripts). Even worse, one concern is that even the tag name is not enough to describe the actual layout of an element. For example, there is this concept of "invalid" markup inherited by MathML3 (e.g. mfrac with three children) which completely changes the layout. Or which can layout as in some specific cases. So to summarize, it's not so straightforward to decide the "right" approach and there is not a simple answer.

The conclusion is that by introducing the new "math" value addressed a concrete use case without breaking existing content or closing the possibility for future changes. On the contrary, introducing more values seem to require more investigation/decision effort and there does not seem to be a justification besides the goal "be more like HTML" (which may not even be achieved since the layout can still completely change depending on other parameters). So at that point it does not seem clear whether there is a strong argument in favor of introducing many more math-specific displays...

In any case, this is something we can keep in mind for the future as we refine mathml core. Igalia is about to send an intent-to-ship for MathML in Chromium and after the conversation this week, and what is important now is to decide whether this issue would be considered a blocker. We believe not, but please tell us if you think otherwise.

[emilio]

Yeah to be clear I'm not sure I'm even a fan of the math display value (it's not clear what it should do on non-MathML elements).

[fred-wang]

@emilio On non-MathML elements Chromium computes it as display: none (similar to what was done for display: contents in some cases), although a later decision from the CSS was to use "mrow layout" ( w3c/mathml-core#105 ) which I guess would be more complicated to implement & test (layout involves operator stretching, automatic spacing, etc) and I'm neither sure what would be the consequence at that point, nor what would be the desired use case.

[bfgeek]

One point to keep in mind is that MathML isn't really its own separate rendering context like SVG - it relies various parts of CSS/HTML today. For example <mtable>, <mtd>, <mtr>, etc.
Today each of those will compute to table, table-cell, table-row respectively.

@emilio What are you advocating for? To make each of the algorithms have a separate display type? Or no special value at all?

(I'm personally in favour for the approach that @fred-wang took here, having a separate math display type).

[emilio]

One point to keep in mind is that MathML isn't really its own separate rendering context like SVG - it relies various parts of CSS/HTML today. For example <mtable>, <mtd>, <mtr>, etc. Today each of those will compute to table, table-cell, table-row respectively.

@bfgeek In Gecko at least, mtable and so compute to display: table-*, but mostly as an implementation detail, since we share a bunch of code with HTML tables... But they are, afaict, the exception rather than the rule.

@emilio What are you advocating for? To make each of the algorithms have a separate display type? Or no special value at all?

I think having a magic math value that works only on MathML elements isn't much different from what e.g. SVG does (where display isn't generally honored, other than none). What advantage does it give you to have a math value, compared to just "assume display is math if it's not none" (which is roughly what SVG does)?

Also, in that case, how do MathML elements with non-math values behave, and is it useful to make them behave in that way?

[bfgeek]

I think having a magic math value that works only on MathML elements isn't much different from what e.g. SVG does (where display isn't generally honored, other than none). What advantage does it give you to have a math value, compared to just "assume display is math if it's not none" (which is roughly what SVG does)?

The ability to use other layout types on MathML elements. Its pretty bad for developers trying to extend MathML if you disallow all other display types.

[fred-wang]

To summarize a bit, the use cases for allowing to override the default rendering of MathML is:

A. Use existing CSS display-inside values (including layout() function for custom layout) to override the default MathML rendering, for polyfills, language extensions, etc
B. Override the XXX > :not(:first-child) { display: none; } on semantics and maction to change their default behavior (i.e. switch between non-none or a none display-inside values). For example show an annotation child of semantics. Or re-implement the legacy actiontype=toggle value of maction.

And I believe the possible implementations are:

1. Always decide rendering based on the tag name.
2. Decide rendering based on the tag name for display-inside: flow. Otherwise, switch to the rendering defined by CSS specs.
3. Decide rendering based on the tag name when display-inside: math (introducing this new value). Otherwise, switch to the rendering defined by CSS specs.
4. Always decide rendering based on display-inside, introducing as many values or properties as needed to represent layout implied by MathML tags and attributes.

And the issue I see:

(1) does not allow to address use cases mentioned above.

(2) almost addresses these use cases, the exception being that one cannot make MathML elements have the normal behavior for display-inside: flow.

(3) addresses the use cases, but it leaves open how to define display-inside: math on non-MathML elements.

(4) addresses the use cases, but it is not clear what would be the right approach, how much work it is to define everything and implement and whether it would have more consequences we are not aware of.

I'm personnally fine with (2) or (3), with a preference for the latter. Basically I suspect web developers could be surprised that the display-inside: flow they are already familiar with behaves specially on MathML elements, while it's easier to document and teach them a new value.

Incidentally, I also prefer saying display-inside: math on non-MathML elements computes to none (rather than "use the mrow algorithm" as requested in w3c/mathml-core#105) as that does not seem an important use case and I'm more confident about how to implement that. We did something similar for display: contents on non-HTML elements.