DRAFT: Intent to Implement: display:contents

[Rune Lillesveen]

Hi,

I threw my display:contents implementation ideas at mste...@opera.com
and I've summarized it in an intent below.

I have a couple of ongoing projects, so I didn't intend to start this
now. Others are free to pick it up if it's a priority. This is just a
dump.


====

Intent to Implement: display:contents

Contact emails: ru...@opera.com

Spec: https://drafts.csswg.org/css-display/#valdef-display-contents


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.

Based on preliminary explorations, it seems we can implement this by
modifying the LayoutTreeBuilder and the LayoutTreeBuilderTraversal to
skip display:contents elements when finding next/previous/parent
LayoutObjects.

Other identified TODOs:

Include <slot> in FlatTreeTraversal.

Store ComputedStyle in rare data for display:contents elements like we
do for display:none elements with getComputedStyle called.

get(Un)CachedPseudoStyles needs to be moved off LayoutObject. For
display:contents, we may still have rendered ::before/::after
elements. An extreme case is a document full of divs with “div {
display: contents } div::before { content: ‘X’ }” which yields a flat
layout tree under body only containing layout boxes for ::before
generated content.

StyleAdjuster needs to consider ComputedStyle for the parent layout
box instead of the inherit (flat-tree) parent for things like
align-self: auto. Gecko does that in their implementation. If you have
a display:flex element and with display:contents descendants, the
closest descendants with layout boxes have their align-self:auto
computed according to the align-items of the display:flex element, not
its inherit parent.


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.


Interoperability and Compatibility Risk

Gecko has shipped display:contents. When Gecko ships Shadow DOM v1,
they will presumable implement <slot> correctly in this regard.

It looks like WebKit (based on looking at commits) so far includes
<slot> in the flat-tree, but implemented the display:contents-ness as
a special case for <slot> without exposing it for author styling, and
without the possibility to override the display value for <slot>.

Need to check Edge/IE.


Ongoing technical constraints

No constraints as such, but an implementation may interfere with 595137


Will this feature be supported on all six Blink platforms (Windows,
Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


OWP launch tracking bug

593328 (Add link to an OWP launch tracking bug)


Link to entry on the feature dashboard


Requesting approval to ship?

No.

--
Rune Lillesveen

[Hayato Ito]

Sounds great. Yeah, I greatly appreciate if someone could pick up "display: content".

It looks you already have a concrete implementation idea. If we could implement it without waiting for Layout NG being finished, that would be nice!

[Rune Lillesveen]

On Fri, Sep 9, 2016 at 4:23 PM, Rune Lillesveen <ru...@opera.com> wrote:

> Other identified TODOs:
>
> Include <slot> in FlatTreeTraversal.
>
> Store ComputedStyle in rare data for display:contents elements like we
> do for display:none elements with getComputedStyle called.
>
> get(Un)CachedPseudoStyles needs to be moved off LayoutObject. For
> display:contents, we may still have rendered ::before/::after
> elements. An extreme case is a document full of divs with “div {
> display: contents } div::before { content: ‘X’ }” which yields a flat
> layout tree under body only containing layout boxes for ::before
> generated content.
>
> StyleAdjuster needs to consider ComputedStyle for the parent layout
> box instead of the inherit (flat-tree) parent for things like
> align-self: auto. Gecko does that in their implementation. If you have
> a display:flex element and with display:contents descendants, the
> closest descendants with layout boxes have their align-self:auto
> computed according to the align-items of the display:flex element, not
> its inherit parent.

+ reattachWhitespaceSiblingsIfNeeded will most likely need to traverse
display:contents subtrees for text nodes.

--
Rune Lillesveen

[Elliott Sprehn]

I think we should file a spec bug here, we need to be able to compute style without having the layout tree exist. The parent box isn't known at this point, just the parent style.

 

If you have
a display:flex element and with display:contents descendants, the
closest descendants with layout boxes have their align-self:auto
computed according to the align-items of the display:flex element, not
its inherit parent.

Yeah, I think we should have the spec changed.

 

--
Rune Lillesveen

--
You received this message because you are subscribed to the Google Groups "style-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to style-dev+unsubscribe@chromium.org.
To post to this group, send an email to styl...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/style-dev/CANz6XvRJVuQb9-nvW3YupyNRhCWY1qOEU-X1SfiyaNvVYqjqjQ%40mail.gmail.com.

[Rune Lillesveen]

On Mon, Sep 12, 2016 at 11:05 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> On Fri, Sep 9, 2016 at 7:23 AM, Rune Lillesveen <ru...@opera.com> wrote:

>> StyleAdjuster needs to consider ComputedStyle for the parent layout
>> box instead of the inherit (flat-tree) parent for things like
>> align-self: auto. Gecko does that in their implementation.

I think I drew the wrong conclusion regarding Gecko's behavior here.
Testing now, it seems they resolve on flat-tree parent, not box
parent.

> I think we should file a spec bug here, we need to be able to compute style
> without having the layout tree exist. The parent box isn't known at this
> point, just the parent style.

Sorry, it was me who forgot about the clarification in the thread started here:

https://lists.w3.org/Archives/Public/www-style/2016May/0250.html

No need to change the spec or StyleAdjuster then.

It should be noted that this means a display:contents element around a
flex item will cause its align-self:auto to not follow align-items for
the flex container. Load this in Firefox:
http://jsbin.com/buzeceteyu/edit

That may seem counter-intuitive.

--
Rune Lillesveen

[Rune Lillesveen]

On Mon, Sep 12, 2016 at 10:47 PM, Rune Lillesveen <ru...@opera.com> wrote:

> + reattachWhitespaceSiblingsIfNeeded will most likely need to traverse
> display:contents subtrees for text nodes.

So, whitespace reattachment is already broken for some shadow dom
cases. I've filed https://crbug.com/648931

Bugs, Naina: this may affect / be affected by your work. I don't know
if reattachments will happen in a different order with your style
recalc / layout tree separation?

By different order, I mean if d1 will be reattached before d2
(flat-tree order) if both separately needs a reattach. Currently, d2
will be reattached before d1 because of tree-of-trees order traversal
in recalcStyle().

<host>
<:shadow-root>
<slot /><div id="d2"></div>
</:shadow-root>
<div id="d1"></div>
</host>

--
Rune Lillesveen

[Bugs Nash]

Order of reattachment should not be affected by our changes.

Bugs

--
Rune Lillesveen

--
You received this message because you are subscribed to the Google Groups "style-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to style-dev+unsubscribe@chromium.org.
To post to this group, send an email to styl...@chromium.org.

To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/style-dev/CANz6XvTmm1rKnDLrX4-gLKuTJrEdBp2_MjhVQVQ5_dJKpd2vkg%40mail.gmail.com.