28591 2015-05-01 17:22:53 +0000 [Shadow]: Figure out a good replacement for /deep/ in testing scenarios 2015-05-27 02:53:38 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED MOVED P2 normal --- 14978 1 dglazkov dglazkov annevk esprehn hayato jackalmage mike public-webapps public-webapps-bugzilla oldest_to_newest 120033 0 dglazkov 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. 120043 1 annevk 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. 120048 2 esprehn 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). 120056 3 annevk 2015-05-04 06:12:37 +0000 Note that an alternative is that we introduce .deepQuery() or some such. 120057 4 esprehn 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. 120069 5 jackalmage 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.) 120221 6 hayato 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? 120224 7 jackalmage 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. 120226 8 hayato 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. 120238 9 jackalmage 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. 120502 10 hayato 2015-05-27 02:53:38 +0000 Moved to https://github.com/w3c/webcomponents/issues/78