Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dbaron opened this issue Oct 24, 2016 · 20 comments

Comments

@dbaron
Copy link
Member

dbaron commented Oct 24, 2016

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
Copy link
Member

TakayoshiKochi commented Nov 15, 2016

The '>>>' combinator was discussed at TPAC 2016 and Google still wants to try it
for static profile.
WICG/webcomponents#78 (comment)

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
Copy link

dylanb commented Mar 31, 2017

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
Copy link

dylanb commented Mar 31, 2017

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
Copy link
Member

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
Copy link

dylanb commented Mar 31, 2017

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

@tabatkins
Copy link
Member

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
Copy link
Member

@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
Copy link

dylanb commented Apr 1, 2017

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
Copy link

dylanb commented Apr 3, 2017

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
Copy link
Member

@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
Copy link
Member

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
Copy link

dylanb commented Apr 6, 2017

@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
Copy link
Member

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
Copy link
Member

zcorpan commented Aug 17, 2017

What is the status here?

@tabatkins
Copy link
Member

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
Copy link
Member

This issue depends on the conclusion of WICG/webcomponents#78 .
Until some alternative is conceived and agreed on, we should keep this in the spec.

@annevk
Copy link
Member

annevk commented Feb 21, 2018

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
Copy link
Member

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

@fantasai
Copy link
Collaborator

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

@annevk
Copy link
Member

annevk commented Apr 21, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants