Contact emails: eco...@igalia.com
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 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, 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 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.
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 , for example).
Interoperability and Compatibility Risk:
Gecko has shipped display:contents 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 ( 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.
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)?
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?