- From: Hayato Ito <notifications@github.com>
- Date: Mon, 25 May 2015 01:49:43 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/78@github.com>
Title: [Shadow]: Figure out a good replacement for /deep/ in testing scenarios (bugzilla: 28591) Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591 ---- comment: 0 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c0 *Dimitri Glazkov* wrote on 2015-05-01 17:22:53 +0000. 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. ---- comment: 1 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c1 *Anne* wrote on 2015-05-02 07:34:03 +0000. 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. ---- comment: 2 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c2 *Elliott Sprehn* wrote on 2015-05-03 00:41:03 +0000. (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). ---- comment: 3 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c3 *Anne* wrote on 2015-05-04 06:12:37 +0000. Note that an alternative is that we introduce .deepQuery() or some such. ---- comment: 4 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c4 *Elliott Sprehn* wrote on 2015-05-04 06:21:02 +0000. (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. ---- comment: 5 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c5 *Tab Atkins Jr.* wrote on 2015-05-05 00:12:16 +0000. (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.) ---- comment: 6 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c6 *Hayato Ito* wrote on 2015-05-07 08:43:56 +0000. (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? ---- comment: 7 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c7 *Tab Atkins Jr.* wrote on 2015-05-07 15:55:04 +0000. (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. ---- comment: 8 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c8 *Hayato Ito* wrote on 2015-05-08 02:25:11 +0000. (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. ---- comment: 9 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591#c9 *Tab Atkins Jr.* wrote on 2015-05-08 17:29:16 +0000. (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. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/78
Received on Monday, 25 May 2015 08:50:12 UTC