Intent to Implement: Slots in a flat tree

[Hayato Ito]

Contact emails

hay...@chromium.org

Spec

CSS Scoping: 3.4. Flattening the DOM into an Element Tree

Summary

Make <slot> elements participate in a flat tree, with UA style: "display: contents".

Until now, we exclude <slot> elements from a flat tree (layout tree). Thus, applying a CSS selector to <slot> doesn't have any affect so far.

"Slots in a flat tree" allows users to apply a CSS selector to <slot> elements, and let <slot>'s assigned nodes inherit a style from its parent <slot> element because the slot becomes the parent in a flat tree.

A <slot> element still doesn't have a Layout Box by default because its UA style is "display: contents".

Motivation

There are two motivations:

1. Improve spec conformance.

There was a long discussion about this behavior. Please see https://github.com/w3c/webcomponents/issues/308 for details.

We decided to exclude slots from a flat tree intentionally when we shipped Shadow DOM v1.

It's time to update the current behavior to improve spec conformance.

2. This change is a necessary part of "Incremental Shadow DOM".

This is a bigger motivation to me.  See the "Incremental Shadow DOM" design doc for details.

Interoperability Risk

Since this is a part of Shadow DOM v1, interoperability matters only with Safari, as of now.

Edge: Public support for Shadow DOM v1

Firefox: Public support for Shadow DOM v1

Safari: Shipped with slots with "display: contents"

Web developers: No signals

Compatibility Risk

Low - Medium.

Unless an existing CSS selector matches <slot> elements, there should be no visible change.

However, for example, if users use "*" (universal CSS selector), the existing selector would unintentionally match <slot> elements.

Then, this would be a user-visible change because slot's assigned nodes would inherit a style from the slot.

I am thinking of adding a use counter to measure this usage.

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

Yes

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5743296429162496

Requesting approval to ship?

No

My concern is that this feature is difficult to implement behind a runtime flag because this feature is tightly related to the heart of rendering, and will change a structure of a flat tree.

I expect that I have to touch a lot of code. It might be unrealistic to implement this behind a runtime flag.

I'll send "Intent to Ship" later once I get more insights on this.

[Rick Byers]

Interesting set of constraints.  Is there an existing UseCounter for ShadowDOM v1 that could give us an upper bound on the compat risk?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_2Xs9fcortOnh4OOwrL-eb_LgB9pRqwrhtx3W0aUKHRAQ%40mail.gmail.com.

[Hayato Ito]

Good question. Per ElementAttachShadow, the upper bound is 0.008%.

Given that the usage of a CSS selector which matches <slot> should be much lower than this number, I can say the compat risk is very low, as of now.

[Boris Zbarsky]

On 10/18/17 5:47 AM, Hayato Ito wrote:
> However, for example, if users use "*" (universal CSS selector), the
> existing selector would unintentionally match <slot> elements.
> Then, this would be a user-visible change because slot's assigned nodes
> would inherit a style from the slot.

The other possible concern there is what happens if someone uses "* {
display: block }" or whatnot.

Has there been any thought around making the "display: contents" style
for "slot" in
https://html.spec.whatwg.org/multipage/rendering.html#flow-content-3 be
!important to avoid this problem?

-Boris

[Hayato Ito]

That can be. As far as I search "!important" in HTML Standard, there are several built-in elements which already use "!important" rules to avoid accidental overwrite by users.

Given that, it would be reasonable to make "display: contents !important" for slots.

Let me file a bug for HTML Standard.