[css-display] math/inline-math

[bkardell]

(Part of #5384 - MathML Core related CSS)

Mathematical rendering, like other text renderings can happen inline with prose or in the block direction and different elements employ different strategies for layout. According to common norms, these are treated a little differently. MathML Core proposes the introduction of two display types:

display: math and display: inline-math

These control box generation and layout according to their tag name, internally. It shoud be possible for authors to experiment/extend and provide custom layouts for when authors would like to override. The figure below illustrates differences in standard treatments of mathematical rendering depending on whether it is inline with text, or has a complete space in the block direction, as illustrated in the figure below.

These can be overridden and extended with custom layouts. display: contents computes to ``none`.

[SebastianZ]

I'd say, the math keyword should be a <display-inside> value, so instead of inline-math it would be inline math.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed math-oriented display values, and agreed to the following:

• RESOLVED: Add 'math' as a <display-inside> value.
• RESOLVED: Add 'inline-math' as a <display-legacy> value.
• RESOLVED: 'math' outside of MathML context computes to 'flow'

The full IRC log of that discussion

<fantasai> Topic: math-oriented display values
<fantasai> github: https://github.com//issues/5385
<fantasai> bkardell_: 2 ways of integrating math into text
<fantasai> bkardell_: inline style or block style
<fantasai> bkardell_: proposal is to add display style
<fantasai> bkardell_: there was a comment in the issue that it should be "inline math" instad of "inline-math"
<fantasai> astearns: It would be a display-inside value
<fantasai> iank_: I think web devs are quite used to 'inline-foo' pattern
<fantasai> iank_: math is an inside display type, but maybe add as an alias
<fantasai> TabAtkins: I agree
<fantasai> TabAtkins: if we were adding a bunch more at once, could maybe make a clean break
<fantasai> TabAtkins: but just one would feel inconsistent
<fantasai> TabAtkins: so would say add inline-math into the table, easy
<fantasai> dholbert: Other places where 'display: contents' is like none?
<fantasai> faceless2: SVG
<fantasai> TabAtkins: various form elements, replaced elements
<fantasai> astearns: So we want ...?
<fantasai> TabAtkins: Add math to <display-inside>, add inline-math to <display-legacy>
<fantasai> iank_: It's basically zero overhead to add inline-math and convenient to authors
<fantasai> astearns: What happens to 'inline-math' on non-MathML elements?
<fantasai> fredw: Would behave like none
<fantasai> faceless2: I thought behaved like mrow
<fantasai> NeilS: Unrecognized elements in MathML context only
<bkardell_> fantasai: generally speaking we try to avoid having things disappear if you do something slightly wrong
<bkardell_> fantasai: I don't think it should behave as display none on unrecognized elements. The fact that display contents does that is really only because we couldnt' think of another way, but that isn't a good pattern
<fantasai> astearns: My expectation was behave like 'flow' on non-MathML element
<fantasai> astearns: either inline or block
<fantasai> iank_: If you have div { display: math; }, will effectively create a block flow internally
<fantasai> fredw: create a block node
<fantasai> iank_: would change box tree slightly
<fantasai> fredw: that's also what we do if don't set display: math on math element
<dholbert> for comparison / reference, data:text/html,<input type="radio" style="display:flex"> still renders as a radio button (we don't force it to display:none)
<fantasai> bkardell_: Unknown element will by default do what you're asking for, but what happens if you set 'display: math' explicitly on it, do something it can't do
<fantasai> fantasai: Ignoring isn't an option, can make it behave as a different value though
<fantasai> RESOLVED: Add 'math' as a <display-inside> value.
<fantasai> RESOLVED: Add 'inline-math' as a <display-legacy> value.
<fantasai> RESOLVED: 'math' outside of MathML context behaves as 'flow'
<fantasai> emilio: Does it behave as or compute to flow?
<fantasai> TabAtkins: whichever is easiest
<fantasai> emilio: compute to is more likely to be easier
<fantasai> emilio: it's what we do for 'display: contents'
<fantasai> RESOLVED: 'math' outside of MathML context computes to 'flow'
<fantasai> emilio: What if you have a non-MathML element inside a MathML element?
<fantasai> fredw: An element not in MathML namespace?
<fantasai> emilio: document.createElement('div') and append to math element
<fantasai> iank_: should work
<fantasai> emilio: should work how?
<fantasai> fredw: not defined
<fantasai> emilio: should be defined
<fantasai> emilio: SVG just doesn't create boxes for those elements
<fantasai> emilio: if you have a random div in SVG, doesn't do much. Not a fan of this.
<fantasai> NeilS: I thought MathML spec said it would be treated as an mrow?
<fantasai> fredw: non-MathML element, so not in the MathML namespace
<fantasai> NeilS: I thought we'd treat as unknown element, whether in mathml namespace or not
<fantasai> iank_: I don't think you specifically want that
<fantasai> iank_: the way that MathML core is currently specified, we can accept arbitrary elements inside MathML subtree
<fantasai> iank_: all the integration points, because more closely tied to CSS, should just work
<fantasai> iank_: if you have a div inside a mathML mrow or something like that, that should lay out as block
<fantasai> fantasai: Should lay out as block inside, whatever MathML wants to do inside
<fantasai> astearns: Seems need to do something around this, but let's get to other issues in the agenda
<faceless2> In SVG, unknown elements collapse to a <g> normally, or a <tspan> if they're inside a <text>
<fantasai> fantasai: Might make sense if you set div { display: math; } then behave same as unknown mathml namespace element with that, treat as mrow
<TabAtkins> Yup, and <mrow> is the mathml equivalent to a <g> basically
<fantasai> emilio: A bit skeptical that that works
<fantasai> emilio: if you put a float inside mathml?
<fantasai> iank_: Like flex/grid, it blockifies.
<fantasai> iank_: doesn't float
<fantasai> emilio: but you need to define these cases.
<fantasai> emilio: how does abspos behave, what's the containing block
<fantasai> emilio: etc.
<fantasai> fredw: tried to write this up in the spec
<fantasai> astearns: Let's raise issue on spec and come back to it some other day
<fantasai> emilio: I don't think these are obscure cases.

[Loirooriol]

Not completely opposed to inline-math, but note we have the precedent of dropping inline-list-item in favor of the space-separated inline list-item.

[fred-wang]

The resolution says 'math' outside of MathML context computes to 'flow' but it seems that would mean outer display is block:

If a value is specified but is omitted, the element’s outer display type defaults to block—except for ruby, which defaults to inline.

which is a bit different to what we discussed. I think we meant "math" and "inline-math" computes to "display flow" or "inline flow" respectively.

[fred-wang]

Note sure that's an argument for introducing the legacy display inline-math but according to MDN, Firefox is the only browser supporting multiple display value: https://developer.mozilla.org/en-US/docs/Web/CSS/display-inside#Browser_compatibility

<div style="display: inline flow"></div> has computed style "inline" in Firefox but "block" in Chrome.

[astearns]

My interpretation was that display-inside:math is what computes to flow outside of a MathML context. So display: inline math would compute to display: inline flow. But @fantasai was translating what I actually said into what made sense to her as she minuted - is this what you meant me to mean, @fantasai?

If that's correct, then I think it follows that display:inline-math computes to display:inline flow in that context.

[fred-wang]

Another note we discussed with @emilio : do we want to add a special case so that the style of a computed display value inline math (or inline math) serializes to inline-math rather than inline math?

[MatsPalmgren]

I don't think we should add inline-math. There's no reason to have that if we add inline math.

Given that <math> by default behaves as an inline in an inline context, it seems more logical that display:math should be the inline variant and display:block math should be the block variant, similar to how ruby/block ruby is designed. Modeling it on an existing similar feature is likely easier to implement and spec, and easier to learn for authors.

[Loirooriol]

@MatsPalmgren I think that's a very good point which I don't see discussed in the minutes. Agenda+ to discuss treating display: math as display: inline math for consistency with ruby.

[css-meeting-bot]

The CSS Working Group just discussed math/inline-math redux, and agreed to the following:

• RESOLVED: to ammend our previous resolution to follow the ruby model and use 2 values only/defaults to inline, as is suggested in the issue

The full IRC log of that discussion

<astearns> topic: math/inline-math redux
<astearns> github: https://github.com//issues/5385#issuecomment-692735088
<fantasai> +1 to mats's suggestion
<bkardell_> fredw: (asking for clarity)
<oriol> +1 to mats
<bkardell_> fantasai: so the default would be that math is inline, and you could say block
<bkardell_> fredw: I think this is related to iank_ suggestions about adding support for the legacy syntax
<bkardell_> fredw: I guess part of the rationale was also that the 2 value syntax isn't supported by all browsers yet
<iank_> I think generally it makes sense for inline-math just for the purposes of that's what web developers are used to expect. :)
<bkardell_> fantasai: I think really it was just about consistency -- he was saying, or tab was saying - there is value for authors in maintaining the consistency since it is a minor add
<bkardell_> faceless2: It would mean you couldn't get it implemented/tested until you had 2 value support in all of the browsers
<bkardell_> fantasai: you could 1 off implement it just for this, but I dont think that would be a good idea. I don't think the parsing problems are diffiult, it's just that there hasn't been a strong motivation for anyone to do it
<bkardell_> fredw: I am curious how you would get block math without supporting this?
<bkardell_> astearns: you couldn't
<NeilS> bkarell: we would like to keep the legacy keyword, right?
<NeilS> fantasai: block-math?
<bkardell_> bkardell_: right: ... nevermind that doesn't make sense
<NeilS> fanstasi: if you ask the chrome team, they probably will tell you that the two keyword version just hasn't been a priority
<bkardell_> chrishtr: I am not concerned about it
<fantasai> s/chrishtr/cbiesinger/
<bkardell_> fredw: I think the parsing is probably easy but then we have to store the value internally and serialize it
<bkardell_> emilio: it's super easy, I know the chrome code for this - it's very easy
<bkardell_> fredw: ok so I guess it should be easy
<bkardell_> oriol: <something>
<bkardell_> astearns: I think I am hearing consensus to follow the ruby model and use 2 values only/defaults to inline
<oriol> s/<something>/I agree it should be easy/
<bkardell_> fredw: what does the serialization look like?
<bkardell_> fantasai: you serialize to the shortest form, so it will serialize as display: math or display: block math
<bkardell_> RESOLVED: to ammend our previous resolution to follow the ruby model and use 2 values only/defaults to inline, as is suggested in the issue

[fred-wang]

Hi, another case that was not very explicit is the case of pseudo elements:

  ::before { content: 'math'; display: math; }
  ::after { content: 'math'; display: block math; }

since they are not MathML elements, I understand they also compute to inline/block flow.

[faceless2]

That seems a shame - if the engine is able to handle pseudo-elements within the Math context, they should be usable, for (eg) equation numbering. Could we redefine non-math elements as "non-pseudo elements in a namespace other than math"?

[fred-wang]

I don't know if there is a right solution, but from an implementation point of view, since these math values are going to allow new combinations and potentially lead to security bugs, I'd prefer to minimize the change if there is not a strong use case.

Note that equation numbering or any other text-only pseudo element can be done with display: block (or other non-math displays), the MathML layout should still be able to handle these non-math displays anyway.

Also, if we want to allow math display on pseudo elements, probably MathML Core will have to say pseudo-elements are laid out as an mrow and the spec updated at each place an "mrow-like" behavior is assumed ; adding special cases for pseudo-elements, which means more spec/test/implementation work. I'm personally not very willing to do this extra work for level 1.

[MatsPalmgren]

but from an implementation point of view, since these math values are going to allow new combinations and potentially lead to security bugs

I think it's the opposite actually - making some values need special handling is usually what complicates implementations. It's also harder to spec, and for authors to learn, a bunch of special rules for a subset of a property's values rather than having the property behave in a uniform way for all its values.

These new math display values should apply to all (pseudo-)elements exactly the same as other display values. So, <math> is from a box construction point of view exactly the same as <div style="display:math">, and conversely, <math style="display:block"> is exactly the same as a plain <div>. The UA sheet should have a math { display: math } rule that the author can override as they see fit (same as we do for <ruby>).

[css-meeting-bot]

The CSS Working Group just discussed [css-display] math/inline-math.

The full IRC log of that discussion

<dael> Topic: [css-display] math/inline-math
<dael> github: https://github.com//issues/5385#issuecomment-745563829
<dael> Rossen_: Is this something we can resolve now and move forward and if anyone has issues we can reopen
<dael> fantasai: Mats prop that display:math outside of MathML should make element behave as an em row. I agree with Mats but Fred thinks more complex to impl. Mats had impl and didn't think it was complicated
<dael> Rossen_: Who was push back on complexity?
<dael> fantasai: Fred
<fantasai> https://github.com//issues/5385
<dael> emilio: Also issue of display:math doing magical things depending on which element. Is there a different issue on that? That's the other concern Mats had
<dael> fantasai: Should be a different issue on that one
<fantasai> https://github.com//issues/5385#issuecomment-700070423
<dael> emilio: I don't [missed] in order to discuss right now
<dael> Rossen_: Doesn't sound like we're ready to discuss
<emilio> s/[missed]/mind filing it, no need to discuss right now
<dael> fantasai: I can't present Fred's PoV. I can point you on the comments. I agree with Mats so could represent that.
<dael> Rossen_: Let's push this on back to the backlog as well
<dael> Rossen_: Perhaps these can be F2F topics
<dael> fantasai: You need to schedule them when the people you want to show up will show up. It's been end of agenda so no one knows to call in
<dael> astearns: I pinged everyone involved and didn't get a response
<dael> Rossen_: Likewise. It's not for lack of trying
<dael> Rossen_: There are going backburner and those that care can bring them back

[bkardell]

So to summarize where I think we are here:

• RESOLVED: Add math as an inline-level display value.
• RESOLVED: Add block math for block-level math.
• Re-opened: Whether display: math on a non-MathML context element makes it behave like mrow or like display: flow.

@MatsPalmgren also posted issues about the mathml box fixup rules and about adding additional internal mathml display values, which should probably be pushed to their own independent issues.

There are some other issues spawned serparately here - I'm not sure what is left on this issue specifically.. Is it literally just whether display:math on a non-MathML context should be more inline or block?

[fantasai]

@bkardell Yeah

[fantasai]

@bkardell Sorry, I misread. The question is whether display: math outside a MathML context should generate an mrow-like box.

[css-meeting-bot]

The CSS Working Group just discussed [css-display] math/inline-math (whether display:math on a non-MathML context should be more inline or block), and agreed to the following:

• RESOLVED: have display:math behave as mrow and ping a11y to see if that's an issue

The full IRC log of that discussion

<dael> Topic: [css-display] math/inline-math (whether display:math on a non-MathML context should be more inline or block)
<dael> github: https://github.com//issues/5385
<dael> astearns: Has been waiting on math people to weigh in. afaict all we need to deal with is display:math on non-MathML
<dael> fantasai: Decided it should be inline
<dael> fantasai: Issue from mozilla is having it behave different if in MathML context or not is not great. Not difficult to impl but more tricky b/c context sensitive. Not necessary for any reason.
<dael> fantasai: Mats asked for it to behave like em row regardless of if on math element or not
<fantasai> s/em row/mrow/
<dael> emilio: and discussion of if need >1. Supposed to be magic depending on valid. If not might need more than one
<fantasai> s/valid/element/
<dael> florian: Assume behavior of making it an em which doesn't contain math is well defined?
<dael> iank_: Yeah, triggers em row layout algo
<fantasai> s/em row/mrow/
<dael> iank_: In simple terms layout things on a row and I think baseline align all
<dael> iank_: I think mathml defines internal types fine. Sometimes mrow if it has more children than expected.
<dael> iank_: I think not having talked to the MathML people I htink I am supportive of adding each display type as FF folks suggest. Seems consistent with everything else. Would like to hear other thoughts.
<dael> iank_: Also works with polyfill story
<dael> fantasai: Two issue. One is display:math outside mathML is mrow behavior. Second is add more display types per mathML element
<dael> plinss: I think have precedent to jsut rely on display property. I would like to see all math in layout not rely on semantics
<dael> plinss: Have it default style
<dael> iank_: If you put display:grid on mrow it has an internal layout type of grid algo. Have consistency there
<dael> florian: Do we need to check with a11y people, a11y tree, to see if the way the build right now will break? My understanding is for some things they build from box rather than element tree. We should check. I don' tknow
<dael> florian: We've been accused of being careless about this in the past
<dael> florian: I hope it doesn't. In theory I support plinss
<dael> plinss: Agree worth investigating. Might justify a bug on AT. We can evaluate when we find out answers
<dael> astearns: Sounding like consensus to have display:math always behave as mrow
<dael> fantasai: Outside MathML context and unless otherwise specified
<dael> astearns: Prop: have display:math behave as mrow and ping a11y to see if that's an issue
<dael> RESOLVED: have display:math behave as mrow and ping a11y to see if that's an issue
<dael> astearns: Separate issue for other math display types?
<dael> fantasai: I believe there is
<dael> astearns: Is there consensus to resolve that now or postpone to future meeting?