Contact emails:
eco...@igalia.com,
re...@igalia.com
Spec:
https://drafts.csswg.org/css-display/#box-generation
Summary:
Implement support for the contents keyword value for the display
property. The contents keyword suppresses generation of layout boxes
for elements which have a computed display of contents. In contrast to
display:none, descendants of elements with display:contents will still
generate layout boxes.
Rune discussed in his draft intent[1] part of the implementation plan,
I plan to stick to most of that plan and identified TODOs.
I've made a rough intent this week just modifying
LayoutTreeBuilderTraversal, and got the expected layout in the acid
test that Gecko has[2], but that's probably not going to be enough,
given that ElementResolveContext uses LayoutTreeBuilderTraversal to
decide the style parent, so I got incorrect styling. My plan to
address this is to split LayoutTreeBuilderTraversal into
LayoutTreeBuilderTraversal and StyleTreeTraversal (better name
suggestions appreciated), making the former based on the later,
filtering display: contents elements on top of it.
Other of the other immediate concerns is where to store the element's
style (given it can't be stored in the LayoutObject). Gecko's
implementation has a HashMap[3] where they store the styles, but for
now I'm using the suggested idea of using the rare data, and it seems
to be working well, though I still need to worry about where to store
the pseudo-elements' style.
Any idea, comment or suggestion here would be very appreciated, I have
different approaches in mind but my plan is to verify them and stick
with the most elegant one.
Motivation:
The <slot> element introduced by Shadow DOM v1 should be part of the
flat tree and be rendered as display:contents by default. Since we
currently do not support display:contents, we have shipped an
implementation of Shadow DOM v1 which does not include <slot> in the
flat tree which means:
* Inheritance through <slot> does not work correctly
* You cannot display <slot> elements by setting the display property
in author style.
* Both points above will cause interop issues with other
implementations when shipped. See next section.
Also, this is a feature that allows some nice use-cases when combined
with CSS grid and flexbox (see [4], for example).
Interoperability and Compatibility Risk:
Gecko has shipped display:contents[5][6] since Firefox 37. When Gecko
ships Shadow DOM v1, they will presumably implement <slot> correctly
in this regard.
It looks like WebKit has implemented display: contents, but only for
the <slot> element ([7] enables it as CSS feature, but they already
had some hard-coded support from looking at that patch). They do want
to implement it properly, though[8].
Don't know about IE/Edge.
Ongoing technical constraints: None
Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?
Yes
OWP launch tracking bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=657748
Link to entry on the feature dashboard:
https://www.chromestatus.com/feature/5663606012116992
Requesting approval to ship?
No
[1]:
https://groups.google.com/a/chromium.org/forum/#!topic/style-dev/nJz270uSkuA
[2]:
http://searchfox.org/mozilla-central/source/layout/reftests/css-display/display-contents-acid.html
[3]:
http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/layout/base/nsFrameManagerBase.h#58
[4]:
https://rachelandrew.co.uk/archives/2016/01/29/vanishing-boxes-with-display-contents/
[5]:
https://bugzil.la/907396
[6]:
https://bugzil.la/1105369
[7]:
https://bugs.webkit.org/show_bug.cgi?id=149439
[8]:
https://bugs.webkit.org/show_bug.cgi?id=157477