Re: [csswg-drafts] [css-display] display: math might not want to do magical box construction based on the kind of element it applies to (#5866)

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 <munderover> which can layout as <msubsup> 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.

-- 
GitHub Notification of comment by fred-wang
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5866#issuecomment-1159533365 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 18 June 2022 18:30:37 UTC