Bug 154765 – ::slotted doesn't work in nested shadow trees

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Ryosuke Niwa]

Created attachment 272386 [details]
Test case

As I commented in https://bugs.webkit.org/show_bug.cgi?id=149441#c8,
::slotted doesn't work when there are nested shadow trees.

See the attached test case.

[Radar WebKit Bug Importer]

<rdar://problem/24870995>

[Antti Koivisto]

The test results look correct to me. The ::slotted selectors in the inner shadow tree match the children of its host, the <inner-host> element in the outer shadow tree. Nothing styles the FAIL2 to case in the <outer-host> so it stays red.

[Antti Koivisto]

Anything else requires selector matching for ::slotted() contents to happen in the composed tree which is not consistent with how things work otherwise.

[Antti Koivisto]

Hmm, maybe it makes sense to do this. It seems logical ::slotted(span) styles all spans in the slot whether they ended up there directly or indirectly.

I think you test case is wrong though. I don't see a rule that would style the foreground of the FAIL2 case to green. This rule

slot[name=inner]::slotted([slot=inner]) { color: green; }

doesn't apply since FAIL2 is not in the <slot name="inner"> of the inner tree. The left side of ::slotted definitely only applies to the current tree.

[Ryosuke Niwa]

(In reply to comment #4)
>
> slot[name=inner]::slotted([slot=inner]) { color: green; }
> 
> doesn't apply since FAIL2 is not in the <slot name="inner"> of the inner
> tree. The left side of ::slotted definitely only applies to the current tree.

Oh oops, yeah, we need to get rid of the leading "slot[name=inner]" there.

[Antti Koivisto]

Created attachment 272448 [details]
patch

[Antti Koivisto]

Created attachment 272449 [details]
patch

[Antti Koivisto]

Comment on attachment 272449 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=272449&action=review

> LayoutTests/fast/shadow-dom/css-scoping-shadow-slotted-nested.html:55
> +            var outerHost = document.querySelector('outer-host');
> +            outerShadow = outerHost.attachShadow({mode: 'closed'});
> +            outerShadow.appendChild(document.getElementById('outer-host-template').content.cloneNode(true));

BTW, I feel the current set of specs desperately needs a declarative way to attach shadow based on a template. Something like <outer-host shadow="outer-host-template"> to replace all this boilerplate.

[Ryosuke Niwa]

Comment on attachment 272449 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=272449&action=review

>> LayoutTests/fast/shadow-dom/css-scoping-shadow-slotted-nested.html:55
>> +            outerShadow.appendChild(document.getElementById('outer-host-template').content.cloneNode(true));
> 
> BTW, I feel the current set of specs desperately needs a declarative way to attach shadow based on a template. Something like <outer-host shadow="outer-host-template"> to replace all this boilerplate.

Indeed.  We've suggested that three years but we've agreed to punt it in v1 so I guess that's that :(
It's really silly that attachShadow or defineElement doesn't take an optional argument though.
e.g.
document.defineElement('my-element', MyElementClass, {template: MyElementClass.template});
would go a long way to simplify this whole setup.

[Ryosuke Niwa]

Comment on attachment 272449 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=272449&action=review

> LayoutTests/fast/shadow-dom/css-scoping-shadow-slotted-nested.html:4
> +    <title>CSS Scoping - ::slotted pseudo element must allow selecting elements assigned to a slot element</title>

Perhaps we should update this title as well?
e.g. ::slotted pseudo element rule must apply to an element that got slotted via another slot

[Ryosuke Niwa]

Comment on attachment 272449 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=272449&action=review

> Source/WebCore/ChangeLog:8
> +

We should probably refer to https://github.com/w3c/webcomponents/issues/331#issuecomment-189191593
since that clarifies this behavior.

[Antti Koivisto]

http://trac.webkit.org/changeset/197316