This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
One thing that immediately popped up once we started talking about removing shadow-piercing combinators is that WebDriver-based tests are frequently interested in reaching into shadow trees to grab a specific element to test: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/test/chromedriver/test/run_py_tests.py&sq=package:chromium&q=testShadowDom*&l=877 Web Driver actually has something currently that attempts to solve the problem: http://www.w3.org/TR/webdriver/#switching-to-hosted-shadow-doms However, the feedback I got from ChromeDriver folks is that it's way too verbose and awkward to use for the most common case (see above). Maybe the solution is just specifying deepQuerySelector for WebDriver spec. However, I want to make sure this is not just a one-off -- seems like this could be needed in other contexts.
1) We shouldn't do features for testing. That's bad. 2) I remain convinced that in the open case we should provide a myriad of features that cross the "deep" to aid with selection, event delegation, composition, etc.
(In reply to Anne from comment #1) > 1) We shouldn't do features for testing. That's bad. > > 2) I remain convinced that in the open case we should provide a myriad of > features that cross the "deep" to aid with selection, event delegation, > composition, etc. +1, we should keep /deep/ in the static profile for querySelector. Before we had it authors kept rolling their own (we saw this on multiple occasions).
Note that an alternative is that we introduce .deepQuery() or some such.
(In reply to Anne from comment #3) > Note that an alternative is that we introduce .deepQuery() or some such. deepQuery is not enough, you don't want to match a descendant selector across a ShadowRoot boundary since ".a .b" means something really different. You'd still need a special combinator to signal where the scope crossing should be in the selector expression. ex. .panel .image All images inside panels contained in a single scope. .panel /deep/ .image All images anywhere below a panel, even if they're inside a nested widget. This is important because it maintains the "don't accidentally cross a boundary" principle. We need something like ::shadow as well.
(In reply to Elliott Sprehn from comment #4) > (In reply to Anne from comment #3) > > Note that an alternative is that we introduce .deepQuery() or some such. > > deepQuery is not enough, you don't want to match a descendant selector > across a ShadowRoot boundary since ".a .b" means something really different. > You'd still need a special combinator to signal where the scope crossing > should be in the selector expression. > > ex. > .panel .image > > All images inside panels contained in a single scope. > > .panel /deep/ .image > > All images anywhere below a panel, even if they're inside a nested widget. > > This is important because it maintains the "don't accidentally cross a > boundary" principle. Yeah, trying to move the shadow-crossing quality to the core of the method doesn't work. It's much less flexible, as you note, and doesn't compose with anything else similar. The correct approach is to just embrace the "static profile" of selectors <http://dev.w3.org/csswg/selectors/#static-profile> and leave /deep/ there. (Or >>>, as it's now called.)
(In reply to Tab Atkins Jr. from comment #5) > (In reply to Elliott Sprehn from comment #4) > > (In reply to Anne from comment #3) > > > Note that an alternative is that we introduce .deepQuery() or some such. > > > > deepQuery is not enough, you don't want to match a descendant selector > > across a ShadowRoot boundary since ".a .b" means something really different. > > You'd still need a special combinator to signal where the scope crossing > > should be in the selector expression. > > > > ex. > > .panel .image > > > > All images inside panels contained in a single scope. > > > > .panel /deep/ .image > > > > All images anywhere below a panel, even if they're inside a nested widget. > > > > This is important because it maintains the "don't accidentally cross a > > boundary" principle. > > Yeah, trying to move the shadow-crossing quality to the core of the method > doesn't work. It's much less flexible, as you note, and doesn't compose > with anything else similar. The correct approach is to just embrace the > "static profile" of selectors > <http://dev.w3.org/csswg/selectors/#static-profile> and leave /deep/ there. > (Or >>>, as it's now called.) Is there any existing clients who use *static-profile*? Does it mean '/deep/' can be used in particular APIs?
(In reply to Hayato Ito from comment #6) > Is there any existing clients who use *static-profile*? > Does it mean '/deep/' can be used in particular APIs? It's for querySelector()/etc.
(In reply to Tab Atkins Jr. from comment #7) > (In reply to Hayato Ito from comment #6) > > Is there any existing clients who use *static-profile*? > > Does it mean '/deep/' can be used in particular APIs? > > It's for querySelector()/etc. Thanks. Can everyone agree that '/deep/' is okay to be used in querySelector()? I think we are assuming that adding something to static profile is zero-overhead to the performance of dynamic profile.
(In reply to Hayato Ito from comment #8) > (In reply to Tab Atkins Jr. from comment #7) > > (In reply to Hayato Ito from comment #6) > > > Is there any existing clients who use *static-profile*? > > > Does it mean '/deep/' can be used in particular APIs? > > > > It's for querySelector()/etc. > > Thanks. > > Can everyone agree that '/deep/' is okay to be used in querySelector()? > > I think we are assuming that adding something to static profile is > zero-overhead to the performance of dynamic profile. Correct. At worst, it's a check during grammar verification, to note that this isn't valid in the current context and so the selector should be considered grammar-violating.
Moved to https://github.com/w3c/webcomponents/issues/78