[css-display] Define how display: contents behaves in MathML. #2167

emilio · 2018-01-06T01:29:33Z

https://drafts.csswg.org/css-display/#unbox defines how display: contents behaves for unusual HTML elements and for SVG elements, but not MathML.

It'd be nice to define how they should behave, even if it's just "it behaves normally".

The text was updated successfully, but these errors were encountered:

tabatkins · 2018-03-21T22:38:52Z

From my reading of MathML3, there's approximately zero elements where it makes sense to use display:contents, so for now I'm defining that it is treated as "display: none" for all of them.

frivoal · 2018-03-22T02:31:05Z

Randomly pulling in someone who ought to know a thing or two about MathML: @pkra, what do you think about the above?

fred-wang · 2018-03-23T10:06:13Z

I discussed this a bit at Igalia. Here is a concrete example:

<math>
  <mfrac>
    <mrow style="background: green; color: red; display: contents">
      <mi>x</mi>
      <mo>+</mo>
      <mi>y</mi>
    </mrow>
    <mn>2</mn>
  </mfrac>
</math>

WebKit and Gecko currently ignore "display: contents" so you will see the fraction numerator with green background.

If instead you treat "display: contents" as "display: none" then it will look like this:

<math>
  <mfrac>
    <mrow style="display: none">
      <mi>x</mi>
      <mo>+</mo>
      <mi>y</mi>
    </mrow>
    <mn>2</mn>
  </mfrac>
</math>

Gecko and WebKit don't create a box for the numerator and so the fraction is rendered as invalid markup (WebKit actually displays nothing because of https://bugs.webkit.org/show_bug.cgi?id=123348) which is different from the current implementation of display: contents. I guess it's easy to implement, just say "display: none" won't create layout/renderer classes and the MathML code will take care of the rest.

Another option is to basically "ignore the math layout" so

<math>
  <mfrac style="background: green; color: red; display: contents">
    <mi>x</mi>
    <mi>y</mi>
  </mfrac>
</math>

is treated as just

<math>
  <mi style="color: red;">x</mi>
  <mi style="color: red;">y</mi>
</math>

with the fraction and background ignored. But things might become more complicated to understand and implement (the first example would be treated as a fraction with 4 elements so invalid) and it's not clear whether there is a concrete use case in practice.

Note that we already have similiar situations like borders or absolute positioning where Gecko or WebKit just ignore CSS properties or choose the option that is the most convenient for implementers. So it seems either keeping "display: content" as it (i.e. ignoring it in MathML element) or changing implementations to match "display: none" is the most appropriate option for MathML.

@emilio: What is your opinion on this? What will be the easiest for Mozilla?

MatsPalmgren · 2018-03-23T13:32:55Z

Handling it as display: none seems like the best option to me. It should be easy to implement for us since display: none is already supported.

tabatkins · 2018-03-23T18:51:36Z

Gecko and WebKit don't create a box for the numerator and so the fraction is rendered as invalid markup

With it acting as display:none, the fraction is invalid because there's only one argument. With it acting as display:contents, the fraction would also be invalid, because there's 4 arguments.

This sort of thing abounds in MathML; every place I saw where I thought display:contents might make sense, it would just as often make things invalid, too. This sort of consideration doesn't apply to HTML's or SVG's rules.

The closest thing we could get to the intent of display:contents would be something like "treat it like an unstyled mrow instead", but that's both complicated (and I don't think it'll work everywhere) and more importantly, not what display:contents does.

So yeah, absent the WG deciding on something totally different, display:none for everything seems best. ^_^

pkra · 2018-03-23T20:41:28Z

Randomly pulling in someone who ought to know a thing or two about MathML: @pkra, what do you think about the above?

I don't know anyone relying on native MathML implementations in a professional production setting (I haven't checked crawler data in a while but it usually confirms this quite broadly). Mixing MathML and CSS is extremely rare in general since MathML usually serves in XML-to-print workflows as well.

So whatever is easiest seems very reasonable.

css-meeting-bot · 2018-04-04T23:33:21Z

The Working Group just discussed ] 'display: contents' on MathML, and agreed to the following resolutions:

RESOLVED: treating display:contents as display:none for MathML

The full IRC log of that discussion

<dael_> Topic: ] 'display: contents' on MathML
<dael_> github: https://github.com//issues/2167
<dael_> TabAtkins: We have special ruels for how display:content should work in SVG. [missed]
<dael_> TabAtkins: How to handle display:contents a few elements treat it like HTML, ones with a transparent content model. Everything else is treated as display:none because children can't be rendered one level up. Looking at mathML there are 0 instances where children can be rendered in outer context.
<dael_> TabAtkins: It would almost never be correct to lift children to outer context. There are a few places where it's right with only a certain number of children. Best thing I can see is make it always display:none on MathML. Firefox des were fine.
<florian> +1
<dael_> astearns: Given other times we said display:contents are handled as display:none and how well they went over I expect this to come up again.
<dael_> TabAtkins: If someone can point to a mathML fucntion where it makes sense we can change this.
<dael_> fantasai: We'll CC mathML WG when we publish a WD
<dael_> florian: And we CCed some MathML people along the way.
<dael_> astearns: You want to talk to math on the web group
<dael_> astearns: Obj ot treating display:contents as display:none for MathML?
<dael_> RESOLVED: treating display:contents as display:none for MathML
<dael_> Topic

…: contents before other suppressions. r=mats,xidorn This also adopts the resolution of [1] while at it, and switches XUL to not support display: contents until a use case appears. This makes our behavior consistent both with the spec and also in terms of handling dynamic changes to stuff that would otherwise get suppressed. Also makes us consistent with both Blink and WebKit in terms of computed style. We were the only ones respecting "behaves as display: none" without actually computing to display: none. Will file a spec issue to get that changed. It also makes us match Blink and WebKit in terms of respecting display: contents before other suppressions, see the reftest which I didn't write as a WPT (because there's no spec supporting neither that or the opposite of what we do), where a <g> element respects display: contents even though if it had any other kind of display value we'd suppress the frame for it and all the descendants since it's an SVG element in a non-SVG subtree. Also, this removes the page-break bit from the display: contents loop, which I think is harmless. As long as the tests under style are based in namespace id / node name / traversal parent, this should not make style sharing go wrong in any way, since that's the first style sharing check we do at [2]. The general idea under this change is making all nodes with computed style of display: contents actually honor it. Otherwise there's no way of making the setup sound except re-introducing something similar to all the state tracking removed in bug 1303605. [1]: w3c/csswg-drafts#2167 [2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700 MozReview-Commit-ID: JoCKnGYEleD

…ore other suppressions. This also adopts the resolution of [1] while at it, and switches XUL to not support display: contents until a use case appears. This makes our behavior consistent both with the spec and also in terms of handling dynamic changes to stuff that would otherwise get suppressed. Also makes us consistent with both Blink and WebKit in terms of computed style. We were the only ones respecting "behaves as display: none" without actually computing to display: none. Will file a spec issue to get that changed. It also makes us match Blink and WebKit in terms of respecting display: contents before other suppressions, see the reftest which I didn't write as a WPT (because there's no spec supporting neither that or the opposite of what we do), where a <g> element respects display: contents even though if it had any other kind of display value we'd suppress the frame for it and all the descendants since it's an SVG element in a non-SVG subtree. Also, this removes the page-break bit from the display: contents loop, which I think is harmless. As long as the tests under style are based in namespace id / node name / traversal parent, this should not make style sharing go wrong in any way, since that's the first style sharing check we do at [2]. The general idea under this change is making all nodes with computed style of display: contents actually honor it. Otherwise there's no way of making the setup sound except re-introducing something similar to all the state tracking removed in bug 1303605. [1]: w3c/csswg-drafts#2167 [2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1453702 gecko-commit: 43862b2ee72eec858f509ce3b9cb5c6fa96194ba gecko-integration-branch: mozilla-inbound gecko-reviewers: mats, xidorn

…her suppressions. This also adopts the resolution of [1] while at it, and switches XUL to not support display: contents until a use case appears. This makes our behavior consistent both with the spec and also in terms of handling dynamic changes to stuff that would otherwise get suppressed. Also makes us consistent with both Blink and WebKit in terms of computed style. We were the only ones respecting "behaves as display: none" without actually computing to display: none. Will file a spec issue to get that changed. It also makes us match Blink and WebKit in terms of respecting display: contents before other suppressions, see the reftest which I didn't write as a WPT (because there's no spec supporting neither that or the opposite of what we do), where a <g> element respects display: contents even though if it had any other kind of display value we'd suppress the frame for it and all the descendants since it's an SVG element in a non-SVG subtree. Also, this removes the page-break bit from the display: contents loop, which I think is harmless. As long as the tests under style are based in namespace id / node name / traversal parent, this should not make style sharing go wrong in any way, since that's the first style sharing check we do at [2]. The general idea under this change is making all nodes with computed style of display: contents actually honor it. Otherwise there's no way of making the setup sound except re-introducing something similar to all the state tracking removed in bug 1303605. [1]: w3c/csswg-drafts#2167 [2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700 Bug: 1453702 Reviewed-by: mats, xidorn MozReview-Commit-ID: JoCKnGYEleD

…: contents before other suppressions. r=mats,xidorn This also adopts the resolution of [1] while at it, and switches XUL to not support display: contents until a use case appears. This makes our behavior consistent both with the spec and also in terms of handling dynamic changes to stuff that would otherwise get suppressed. Also makes us consistent with both Blink and WebKit in terms of computed style. We were the only ones respecting "behaves as display: none" without actually computing to display: none. Will file a spec issue to get that changed. It also makes us match Blink and WebKit in terms of respecting display: contents before other suppressions, see the reftest which I didn't write as a WPT (because there's no spec supporting neither that or the opposite of what we do), where a <g> element respects display: contents even though if it had any other kind of display value we'd suppress the frame for it and all the descendants since it's an SVG element in a non-SVG subtree. Also, this removes the page-break bit from the display: contents loop, which I think is harmless. As long as the tests under style are based in namespace id / node name / traversal parent, this should not make style sharing go wrong in any way, since that's the first style sharing check we do at [2]. The general idea under this change is making all nodes with computed style of display: contents actually honor it. Otherwise there's no way of making the setup sound except re-introducing something similar to all the state tracking removed in bug 1303605. [1]: w3c/csswg-drafts#2167 [2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700 MozReview-Commit-ID: JoCKnGYEleD UltraBlame original commit: 43862b2ee72eec858f509ce3b9cb5c6fa96194ba

fantasai added the css-display-3 Current Work label Jan 11, 2018

tabatkins closed this as completed in 1d3e6a0 Mar 21, 2018

fantasai added the Agenda+ label Mar 21, 2018

fantasai reopened this Mar 21, 2018

css-meeting-bot removed the Agenda+ label Apr 4, 2018

fantasai added the Closed Accepted by CSSWG Resolution label Apr 5, 2018

fantasai closed this as completed Apr 5, 2018

moz-wptsync-bot mentioned this issue Apr 16, 2018

[Gecko Bug 1453702] css-display] Move unboxing to style, and handle display: contents before other suppressions. web-platform-tests/wpt#10489

Merged

fantasai added the Tracked in DoC label Jun 21, 2018

fred-wang mentioned this issue Aug 26, 2019

Make display:contents map to display:none w3c/mathml#90

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-display] Define how display: contents behaves in MathML. #2167

[css-display] Define how display: contents behaves in MathML. #2167

emilio commented Jan 6, 2018

tabatkins commented Mar 21, 2018

frivoal commented Mar 22, 2018

fred-wang commented Mar 23, 2018 •

edited

Loading

MatsPalmgren commented Mar 23, 2018

tabatkins commented Mar 23, 2018

pkra commented Mar 23, 2018 •

edited

Loading

css-meeting-bot commented Apr 4, 2018

[css-display] Define how display: contents behaves in MathML. #2167

[css-display] Define how display: contents behaves in MathML. #2167

Comments

emilio commented Jan 6, 2018

tabatkins commented Mar 21, 2018

frivoal commented Mar 22, 2018

fred-wang commented Mar 23, 2018 • edited Loading

MatsPalmgren commented Mar 23, 2018

tabatkins commented Mar 23, 2018

pkra commented Mar 23, 2018 • edited Loading

css-meeting-bot commented Apr 4, 2018

fred-wang commented Mar 23, 2018 •

edited

Loading

pkra commented Mar 23, 2018 •

edited

Loading