[css-scoping-1] should shadow-piercing descendant combinator (>>>) still be in specification

[dbaron]

css-scoping-1 currently specifies the shadow-piercing descendant combinator (>>>).

However, the minutes of the April 2015 Web Components meeting have, in their summary of discussion of contentious bits, say:

Contention point: E. Shadow boundary-piercing combinators Apple: Must not work in closed mode; think named parts is better model Mozilla: Would like to postpone piercing to v2 Microsoft: Would like a named parts model Google: Think piercing was a mistake, should be removed Resolution: Remove

This suggests that perhaps the feature should not still be in css-scoping.

[TakayoshiKochi]

The '>>>' combinator was discussed at TPAC 2016 and Google still wants to try it for static profile. https://github.com/w3c/webcomponents/issues/78#issuecomment-248560978

People agreed on removing it from dynamic profile, though.

FYI, Chromium's issue for '>>>' is https://bugs.chromium.org/p/chromium/issues/detail?id=633007

[dylanb]

Does the '>>>' combinator select shadow DOM nodes? I cannot get the Google implementation in Chrome 56 to select anything but the light DOM nodes that have been slotted into the shadow DOM.

For example, if you go to this page http://dylanb.github.io/Axponents/web_components.html and try the following code in the console document.querySelectorAll('div.custom aria-menubar >>> *') you will see only light nodes selected

I am asking about the intended behavior because we are trying to decide whether to use this feature in future code and I don't want a potential bug or partial implementation in the Google code to adversely affect that decision.

[dylanb]

ok, so after reading the linked-to Chrome issue, I see that their code does not support v0 and does work for me in v1 shadow DOM.

Is this combinator intended to work in both v0 and v1?

[tabatkins]

There are no plans to add any new features to v0, or improve it at all; we'll be removing it as that becomes possible. It's definitely in a "security fixes only" state.

[dylanb]

@tabatkins so can I take that as a "this will never work in v0"?

[tabatkins]

If it doesn't work now, there's no intention of making it work in the future, no. v0 is a dead-end tech.

[TakayoshiKochi]

@dylanb as you already saw, Chrome implements >>> under experimental flag, and it works only for v1 shadow roots and in querySelector. For v0 - you can still use /deep/ in Chrome (and without experimental flag), although using v0 feature for any new thing is not recommended. Exactly what @tabatkins said, 'v0 is a dead-end tech'.

If you find >>> useful, please let us know, as we are still waiting for feedback for convincing use cases in real world.

[dylanb]

We are trying to figure out how to create an address for elements that violate an accessibility rule in the axe-core project. The address needs to work for light and shadow elements. We normally create CSS selectors for this purpose and are looking at the >>> combinator to allow us to continue to create a CSS selector when we support shadow DOM.

[dylanb]

So I just figured out that we cannot use this combinator to achieve what we want. If you'd like to follow along, please take a look at this page: http://dylanb.github.io/shadowDOM/v1_menu_example.html

If you run this code: document.querySelectorAll('div >>> ul.menucontainer'), you will see it selects 3 elements

You can create a unique selector to select the last two of these elements, these selectors are:

document.querySelectorAll('div > li:nth-of-type(2) >>> ul.menucontainer')
document.querySelectorAll('div > li:nth-of-type(1) >>> ul.menucontainer')

however there is no unique selector for the first one. In other words, when you have shadow DOM inside shadow DOM, you can only be guaranteed to uniquely address elements in the shadow DOM that are direct descendants of a light DOM node AND have no children with shadow roots. For all other elements in the shadow DOM, there is no selector that can be guaranteed to be unique.

What I really need is a "single level piercing child combinator". So >>> would be the piercing equivalent of > and >>>> would be the piercing equivalent of >> or something along those lines

[TakayoshiKochi]

@dylanb I see your problem, that you need a unique selector to identify any element in the whole tree.

I'm not sure that "there should be at least one selector to uniquely identify any element in shadow-including document", is a requirement for CSS selectors or not. Without shadow, apparently you can use > and all the tree from document to give a path to uniquely identify any element.

So for completeness for that requirement, having 2 different combinator for "one-shadow' and "multiple-shadows" makes sense.

@tabatkins do you have any idea whether such a requirement exists, or makes sense?

[tabatkins]

It's not a general requirement, no. Before the advent of :nth-child(), it definitely wasn't true of ordinary CSS; if you wanted a unique path, you had to make sure it was unique yourself, and possible add a uniquifier, like an ID. The "supported in stylesheets" variants of shadow selectors we appear to be settling on (::part()) also don't support that requirement, since they're equivalent to classes.

[dylanb]

@tabatkins before you could use XPath to achieve a unique address, once :nth* appeared you could use a combination of descendant selectors and :nth-*

There has been a way to uniquely address any node in a document for a very long time without having to change the document and add IDs (with the exception of IE) and that is now no longer possible with shadow DOM

[TakayoshiKochi]

A page author can add an ID on an element to uniquely identify the element in a page, even with Shadow DOM. The problem @dylanb is raising is whether third-party tool (other than the page author itself) can address any element uniquely.

IMHO, the web platform is already providing a way to uniquely identifying an element, so this could be a hard ask for web platform to add solution for the requirement, unless the use case is also viable for web authors. (this question is also true for >>>, which this issue is about.)

[zcorpan]

What is the status here?

[tabatkins]

Piercing shouldn't be in the dynamic profile; no reason for it to be removed from the static profile (it doesn't grant any new powers beyond what JS can already do by manually tree-walking). There's at least one implementation of it for JS, so unless things change, I'm not planning on removing it from Scoping.

[TakayoshiKochi]

This issue depends on the conclusion of https://github.com/w3c/webcomponents/issues/78 . Until some alternative is conceived and agreed on, we should keep this in the spec.

[annevk]

I think the conclusion there is that this is still actively opposed by Apple as stated by @rniwa. And given that this has only utility for open shadow trees I think I can say that Mozilla is supportive of that position. So I'd like to see this removed from CSS Scoping.

[TakayoshiKochi]

FYI: I'm working on removing the experimental implementation in Blink at https://bugs.chromium.org/p/chromium/issues/detail?id=829713

[fantasai]

Also, implied CSSWG approval at https://lists.w3.org/Archives/Public/www-style/2018Jan/0004.html

[annevk]

@fantasai, FWIW, those minutes seem to be about >>, not >>>.