Remove Shadow-Piercing descendant combinator, '/deep/' (aka '>>>'), and '::shadow' pseudo-element |
|
||||||||||||||||||||||||||||||
Project Member Reported by hayato@chromium.org, May 20 2015 | Back to list | ||||||||||||||||||||||||||||||
Issue descriptionDropping this feature is the resolution at Web Components f2f meeting [1]. This is a meta bug to track all efforts to remove these features from Blink. [1] https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting
Jun 4 2015
,
The following revision refers to this bug: http://src.chromium.org/viewvc/blink?view=rev&rev=196442 ------------------------------------------------------------------ r196442 | hayato@chromium.org | 2015-06-04T01:03:47.394773Z Changed paths: M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/content-deep-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/css/invalidation/targeted-class-shadow-combinator-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/parser/CSSSelectorParser.cpp?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/content-pseudo-element-with-deep-combinator-and-host-pseudo-class-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/SelectorAPI/only-shadow-host-in-shadow-tree-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/Source/core/css/SelectorChecker.cpp?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/content-pseudo-element-with-shadow-pseudo-element-and-host-pseudo-class-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/stylesheets-order-in-shadow-dom-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/all-in-shadow-tree-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/querySelector-with-distribution-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/querySelector-for-multiple-shadowroots-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/css/invalidation/shadow-boundary-crossing-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/cascade-of-treeboundary-crossing-rules-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/querySelector-with-shadow-all-and-shadow-deep-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/css/invalidation/detach-reattach-shadow-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/shadow-pseudo-element-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/style-and-shadow-element-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/querySelector-for-useragent-shadowroot-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/querySelector-with-detached-node-distribution-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/style-with-deep-combinator-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/style-with-shadow-pseudo-element-expected.txt?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/Source/core/frame/UseCounter.cpp?r1=196442&r2=196441&pathrev=196442 M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/dom/shadow/dynamically-added-deep-combinator-and-shadow-pseudo-element-expected.txt?r1=196442&r2=196441&pathrev=196442 Add a deprecation message for shadow-piercing descendant combinators and shadow pseudo elements. Deprecate /deep/ and '::shadow'. "Intent to Deprecate" is here: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/68qSZM5QMRQ/pT2YCqZSomAJ Note that there is a plan to support these selectors in the static profile, however, this is still in the discussion. I'll support these selectors again in the static profile in another patch when the discussion settles down. This CL deprecates all usages of these selectors, both in the static profile and the dynamic profile. BUG= 489954 Review URL: https://codereview.chromium.org/1166833002 -----------------------------------------------------------------
Jun 13 2015
,
Hello, when are you planning to stop supporting '/deep/'? I'm asking because removing '/deep/' will break several Chromium and Chromium OS Web UIs.
Jun 15 2015
,
Thank you for letting me know it. I think that depends on the usage of the /deep/. I'll follow the standard procedure of Deprecation: http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation If the usage number of /deep/ is low enough to remove, I'll remove it. However, Chromium and Chromium OS Web UIs are apparently blocking issues to stop supporting /deep/ for us. Please update this issue if you have a blocking issue to remove it from Web UIs. We can't remove /deep/ while Chromium and Chromium OS Web UIs are still using it.
Jun 26 2015
,
Please don't remove the ::shadow selector. I'm speaking as a developer here, and a web user. The workaround for selecting data or elements inside shadow documents is then to write a custom version of querySelector that traverses and selects using the shadowRoot.querySelector method. It's easier to simply be able to specify that similar behaviour occurs by using a ::shadow selector inside the top level document.querySelector call, that to write a polyfill because ::shadow is deprecated. Why have you decided to deprecate it? Isn't the W3C process to bring out these standards docs important, in that we can then rely on the standards reflecting the roadmap? If so how can we just raise a bug, diverge from this roadmap, and then say we're not going to support a feature anymore ? It's an invalid argument to say "remove them because of low usage" because web components have not yet had enough time to reach significant usage levels, and yet their potential for future use is huge. AJAX took many years to really change the way web apps worked. Web Components may be the same. It seems it would work to be a little more future-proof and forward thinking by supporting standards like web components (::shadow being a part) that will help advance what we're doing on the web. I don't think Chrome should shy away from being a pioneer. So what if no other browsers support something? Chrome is the best, it can legitimately set the example. Doing so when it aligns with the W3C doc is really not controversial. So it seems strange to want to remove a feature. Personally, I found a lot of uses for ::shadow, particularly in chrome apps and extensions, and I never uses deep very much. A workaround is not impossible, it's just fixing something that doesn't have to be broken. Keep the ::shadow!!
Jun 26 2015
,
Thank you for the feedback. As comment #1 said, removing "::shadow" is the resolution at Web Components f2f meeting [1]. I'm afraid that bug tracker in chromium is not a good place to discuss this kind of topic. Web Components Issues [2] or public-webapps@w3c.org [3] ML is a good place to raise such a request. Would you be willing to give us a feedback there? [1] https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting [2] https://github.com/w3c/webcomponents/issues/ [3] https://lists.w3.org/Archives/Public/public-webapps/
Jun 26 2015
,
No, /deep/ and friends are still valid in querySelector. They're being removed from the "dynamic" profile, but kept in the "static". http://dev.w3.org/csswg/selectors/#profiles
Jul 14 2015
,
#7, then why does Chrome produce deprecation warning when I call document.querySelector('html /deep/ *') in JS? Chrome version: 45.0.2453.0 dev (64-bit)
Jul 14 2015
,
I have a plan to remove deprecation warning from the static profile. I've explained it in this CL's description: https://codereview.chromium.org/1166833002
Jul 14 2015
,
FYI. The spec discussion is here: https://github.com/w3c/webcomponents/issues/78
Jul 16 2015
,
We have been using /deep/ combinator and other shadow piercing combinators extensively for sharing styles across components. Can someone please tell me how can we achieve this?? -- https://github.com/w3c/webcomponents/issues/282
Aug 31 2015
,
Varunkumar.N say your common styles are in a file called common-style.css In your component have a style tag that is like this <style> @import url( '<path_to>/common-style.css' ); </style> This inverts the control : instead of broadcasting your styles for anyone to use, style consumers must know which styles they want and actively request them, which helps avoid conflicts. With browser caching, there's essentially no penalty to so many imports, in fact it is likely faster than cascading the styles through multiple shadow trees using piercers.
Aug 31 2015
,
I'd love a recommendation from you guys. In Aurelia we have a custom behavior named "show" that, based on its value either shows or hides the associated HTML element. We do this by adding or removing a class on the element. The class itself is dynamically defined and injected into the document head. Here's some pseudo code: if (hasShadowDOM) { injectStyles('body /deep/ .aurelia-hide { display:none !important; }'); } else { injectStyles('.aurelia-hide { display:none !important; }'); } If support for the deep selector is removed, how can we make this behavior work in a universal way? Developers may choose to use "show" inside shadow dom or inside light dom. How can we ensure that applying the class will result in the desired behavior, regardless of where it is applied? The removal of /deep/ will cause a critical break to almost every Aurelia app. I imagine this will also affect Angular and many other frameworks in roughly the same way. I'm sure the standards body must have considered this extremely common scenario. What would be the recommendation to solve this problem?
Sep 17 2015
,
Good bye to DevTools' custom themes :(
Sep 23 2015
,
Now getting deprecation warning in MeteorJS 1.2.0.1 (Latest Stable) [1] [1] https://www.meteor.com/
Sep 23 2015
,
This issue likely requires triage. The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days). Thanks for helping out! -Anthony
Sep 25 2015
,
The status update: There is no timeline to remove /deep/ (or ::shadow) from chromium, as of now. We can't remove /deep/ in the near future because the usage [1] is too high. We are likely to continue to support it for a while, maybe for a couple of quarters, or years. :( As for the static profile, I'll un-deprecate /deep/ in the static profile if other browser vendors agree that we should support /deep/ in the static profile [2]. However, I think that won't happen soon. [1] https://www.chromestatus.com/metrics/feature/timeline/popularity/471 [2] https://github.com/w3c/webcomponents/issues/78
Oct 20 2015
,
Can we at least make sure an alternative is available for external styling of shaded elements before removing this? We've been advising people to use ::shadow .class { } to apply custom styling (usually hiding) to certain controls in a custom element and the removal would leave us stranded with no alternative but to back out our use of Shadow DOM. One proposal is custom pseudo-elements[1], which sounds like a better approach than ::shadow .class { } anyway. Another is @apply[2]. Both aren't particularly mature at the moment, though. [1]: https://github.com/w3c/webcomponents/issues/300 [2]: http://tabatkins.github.io/specs/css-apply-rule/
Oct 21 2015
,
Yeah, basically, I'll follow the standard process [1] to remove, however, it's unlikely to remove this unless there is a matured alternative way. I think the communication is very important here. Thank you for rising your concern! [1] http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation
Nov 2 2015
,
Dec 9 2015
,
Hello! I have been redirected here from my browser. It appears I got a virus. My second opened tab always redirects me to some junk website and when I looked through the code of the link in the history, I saw the message '/deep/ combinator is deprecated'. Is there any way to fix it?
Dec 17 2015
,
How do I remove all this I am not a developer and do not want any of this. I do not even know how I got this. Especially if it is a bug. Barb Beath
Feb 9 2016
,
I have had a virus that has come through my google browser that is usinga microsoft shell program and redirecting my web searches whenever I get close to getting him or her out. I reset my Bios system, host took over administrator privileges and has basically taken over my system. I am glad someone is aware of browser problems. I haven't studied programming in about 20 years so I know I can't do it. Interesting discussions> could use solution now. Any help would be greatly appreciated
Feb 9 2016
,
how do you remove it? i dont even know what i done please help me.....
May 19 2016
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1b0aab34b5ef9e168f1627703da1cc07c092ab62 commit 1b0aab34b5ef9e168f1627703da1cc07c092ab62 Author: shans <shans@chromium.org> Date: Thu May 19 02:24:39 2016 Better counting of /deep/ usage Better counting of /deep/ usage. The new counter will only trigger when /deep/ does something different to the standard descendant combinator. BUG= 489954 Review-Url: https://codereview.chromium.org/1988543002 Cr-Commit-Position: refs/heads/master@{#394640} [modify] https://crrev.com/1b0aab34b5ef9e168f1627703da1cc07c092ab62/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/1b0aab34b5ef9e168f1627703da1cc07c092ab62/third_party/WebKit/Source/core/frame/UseCounter.h [modify] https://crrev.com/1b0aab34b5ef9e168f1627703da1cc07c092ab62/tools/metrics/histograms/histograms.xml
Aug 5 2016
,
+shans@
Sep 30 2016
,
Status update: As of now, we do not have any ETA to remove these features. Note: These features are between at stage 4 and 5 in a deprecation process: http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation
Oct 12 2016
,
Jan 18 2017
,
Since there's no concrete timeframe for removal, I suggest we remove the deprecation warning. We want to reserve deprecation warnings for things that are actually about to cause problems for developers in order to reduce the risk of warning blindness.
Jan 18 2017
,
Note that instead of removing the warning, we could just consider downgrading it to a 'violation': https://bugs.chromium.org/p/chromium/issues/detail?id=568218#c16. Thoughts?
Jan 18 2017
,
Jan 19 2017
,
If the “violations”-reporting mechanism gets implemented, then I think this case is definitely one that should become such a violation—instead of the message just being removed altogether. As I wrote over in a comment over at bug 568218, I think many authors would value being able to opt-in to won't-show-on-console-by-default-but-can-be-enabled stricter reporting when they want it.
Jan 19 2017
,
Jan 19 2017
,
Hmm. That might make sense. However, can we defer the decision until https://bugs.chromium.org/p/chromium/issues/detail?id=632009 is fixed? The deprecation of /deep/ is a kind of *pre-requirement* of the next big deprecation, deprecating Shadow DOM v0 itself. We can say that the deprecation of /deep/ is a subset of the deprecation of Shadow DOM v0. I think removing the usage of a /deep/ combinator is the most important pre-requirement for developers to switch from v0 to v1.
Mar 23 2017
,
The predictability program is reviewing the top 50 starred Blink bugs this quarter, and this is 48 on that list. We’re hoping that for each we can set a target milestone, or set a NextAction date so that we know when to check back in. hayato, other than issue 632009 is there any other concrete plan for trying to decrease usage of these APIs? Do we have, for example, HTTP Archive or GitHub search results showing specific sites/libraries using it where we could do outreach? See https://www.chromium.org/blink/platform-predictability/compat-tools and https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit for some ideas of how we might move forward here. Happy brainstorm ideas more if you like. Note that issue 632009 currently says work will start "in a couple quarters", so I don't think that counts as a concrete plan.
Mar 23 2017
,
/deep/ and ::shadow removal are not blocked on 632009. In fact, I've been looking into /deep/ removal specifically this week. The usage count is now less than 0.02%. Further, if we replace /deep/ with the descendant combinator rather than just marking selectors using /deep/ as invalid, sites with a combination of /deep/ and shadow DOM are the only sites that will observe a change in behavior. We're tracking a count for these sites too, and it's around 0.0065%. I'd say from a usage perspective we're good to go. That leaves two remaining issues: (1) AdBlock plus make use of shadowDOM v0. However, in private communication with them I've learned that they do *not* make use of the /deep/ combinator. (2) our i18n support in WebUI makes use of /deep/. I'm going to try to talk to someone about this today, and can report back here.
Mar 23 2017
,
I had a quick chat with dbeam@ (cc'd), who is optimistic that the remaining dynamic uses of /deep/ in i18n can be removed pretty soon. He's going to make sure this is true and report back - once we know it is, we can probably send out an intent to remove. If it does turn out that i18n support still needs /deep/, I can devote some cycles to trying to rectify.
Mar 23 2017
,
these are the files you might still have problems with $ git grep -l 'i18n-content' -- chrome/browser/resources/ | xargs grep -l polymer chrome/browser/resources/chromeos/arc_support/main.html chrome/browser/resources/chromeos/login/arc_terms_of_service.html chrome/browser/resources/chromeos/login/controller-pairing-screen.html chrome/browser/resources/chromeos/login/gaia_password_changed.html chrome/browser/resources/chromeos/login/header_bar.html chrome/browser/resources/chromeos/login/host-pairing-screen.html chrome/browser/resources/chromeos/login/lock.html chrome/browser/resources/chromeos/login/offline_gaia.html chrome/browser/resources/chromeos/login/oobe.html chrome/browser/resources/chromeos/login/oobe_buttons.html chrome/browser/resources/chromeos/login/oobe_eula.html chrome/browser/resources/chromeos/login/oobe_hid_detection.html chrome/browser/resources/chromeos/login/oobe_update.html chrome/browser/resources/chromeos/login/oobe_welcome.html chrome/browser/resources/chromeos/login/oobe_welcome_dialog.html chrome/browser/resources/chromeos/login/saml_confirm_password.html chrome/browser/resources/chromeos/login/saml_interstitial.html chrome/browser/resources/chromeos/login/unrecoverable_cryptohome_error_card.html chrome/browser/resources/chromeos/network_ui/network_ui.html chrome/browser/resources/inline_login/inline_login.html alemate@ and achuith@ are the main owners (CC'd). just spoke with them and they have some slightly more complex requirements around how they i18n pages (it's dynamic), so they can't as easily switch to our $i18n{} preprocessing mechanism. I'm fairly confident we could come up with a solution or just live with some flicker or hardcode some spaces (i.e. just inject inside the shadow roots they care about) to remove /deep/.
Mar 23 2017
,
ChromeOS OOBE/signin needs to be able to switch UI language on the fly (without page reloading). This means we need to do it on the renderer side. I think the best solution could be to integrate $i18n{} as core blink function, so that we could replace strings on the fly without page reloading. ;) Otherwise we will have to stuck forever with JS, which is slow.
Mar 23 2017
,
to expand a little bit on what I meant, if we remove /deep/ but want to ensure empty nodes (that haven't been internationalized yet) have a line of text, we can change <div i18n-content=blah></div> to <div i18n-content=blah> </div> which is really all the CSS was doing anything (through content:).
Mar 23 2017
,
I was thinking of adding the timeline to the deprecation message clearly, e.g. about one year later; 2018/03/31, however, that was not done yet. See "intent to deprecate" thread for details (sorry, the thread is too long): https://groups.google.com/a/chromium.org/d/msg/blink-dev/68qSZM5QMRQ/TJGCKM6fDwAJ What do you think of adding the timeline, 2018/03/31? Does this sound a feasible plan for you? I also thought that we should wait for the date of launching Polymer 2.0 before adding a clear removing timeline to the deprecation message. However, I am not sure 100% sure how Polymer 2.0 is relevant here.
Mar 23 2017
,
I think we can do a lot better than that. An intent to remove could give a removal timeline of 1, perhaps 2 milestones in the future. The danger with providing a long removal timeline is that usage could change a lot in that time. If we want to remove, we should do it now while usage is low. Polymer 2.0 isn't relevant here :) The Polymer team has done a lot of good work deprecating and removing usage of /deep/ in 1.0, which is why the use counters are low.
Mar 23 2017
,
I see. Given the new information such as: (1) AdBlock plus make use of shadowDOM v0. However, in private communication with them I've learned that they do *not* make use of the /deep/ combinator. (2) the remaining dynamic uses of /deep/ in i18n can be removed pretty soon. (3) We're tracking a count for these sites too, and it's around 0.0065%. I think we can be more aggressive to remove /deep/, in 2 milestones or something. If everyone is okay, let me send an "Intent to remove". shans@, > The usage count is now less than 0.02%. Further, if we replace /deep/ with the descendant combinator rather than just marking selectors using /deep/ as invalid, sites with a combination of /deep/ and shadow DOM are the only sites that will observe a change in behavior. We're tracking a count for these sites too, and it's around 0.0065%. I do not fully understand this explanation. Could you share how to *reproduce* 0.0065% with us?
Mar 23 2017
,
I think what shans@ meant was: https://www.chromestatus.com/metrics/feature/timeline/popularity/1375 https://codereview.chromium.org/1988543002 Some sites may just use /deep/ without real shadow roots, so the code counts if the right-hand side of /deep/ is in a shadow tree. If the matched element is not in a shadow, replacing "/deep/" with " " in the selector should also match the element, so 0.0065% reflects reality more on meaningful usage of /deep/. shans@, correct me if I'm wrong.
Mar 23 2017
,
Sounds great, looking forward to the intent-to-remove discussion!
Mar 23 2017
,
kochi@, that is exactly correct. Concretely, take a rule such as: .a /deep/ .b { ... } removing /deep/ altogether would cause this rule to parse as an error, but parsing /deep/ as an alias for " " will cause this rule to work identically on pages with no shadow DOM. Only about 1/3 of pages that use /deep/ currently contain shadow DOM, so aliasing /deep/ is an effective strategy for reducing page breakage.
Mar 24 2017
,
Thank you kochi@ and shans@. As we chatted offline, we are going to send an "Intent to remove".
Mar 28 2017
,
Here is the "Intent to Remove" thread in blink-dev: - https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HX5Y8Ykr5Ns See also chromestatus entry: Make /deep/ behave like the descendant combinator " ": - https://www.chromestatus.com/feature/4964279606312960
Mar 29 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/efa081e7cade69a78de92f0548ad80d440cec7e6 commit efa081e7cade69a78de92f0548ad80d440cec7e6 Author: hayato <hayato@chromium.org> Date: Wed Mar 29 07:07:18 2017 Add removal date to ::shadow and /deep/ Intent to Remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HX5Y8Ykr5Ns BUG= 489954 Review-Url: https://codereview.chromium.org/2776073004 Cr-Commit-Position: refs/heads/master@{#460308} [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/css/deep-cascade-order-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/css/invalidation/detach-reattach-shadow-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/css/invalidation/shadow-boundary-crossing-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/css/invalidation/targeted-class-shadow-combinator-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/apply-deep-in-document-scope-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/cascade-of-treeboundary-crossing-rules-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/content-deep-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/content-pseudo-element-with-deep-combinator-and-host-pseudo-class-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/content-pseudo-element-with-shadow-pseudo-element-and-host-pseudo-class-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/dynamically-added-deep-combinator-and-shadow-pseudo-element-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/shadow-pseudo-element-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/style-and-shadow-element-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/style-with-deep-combinator-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/style-with-shadow-pseudo-element-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/fast/dom/shadow/stylesheets-order-in-shadow-dom-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/shadow-dom/v0/cascade-deep-in-v1-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/LayoutTests/shadow-dom/v0/closed-mode-deep-combinator-and-shadow-pseudo-expected.txt [modify] https://crrev.com/efa081e7cade69a78de92f0548ad80d440cec7e6/third_party/WebKit/Source/core/frame/Deprecation.cpp
Apr 25 2017
,
May 8 2017
,
May 11 2017
,
May 15 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60 commit a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60 Author: hayato <hayato@chromium.org> Date: Mon May 15 06:33:13 2017 Make /deep/ as no-op and remove ::shadow in dynamic profile Intent to Remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HX5Y8Ykr5Ns To make this CL small one, and easy to be reverted, all tests which depend on /deep/ (or ::shadow) were either removed or updated in another CL: https://bugs.chromium.org/p/chromium/issues/detail?id=715034. This CL only touched the small part so that users can't use /deep/ or ::shadow in CSS dynamic profile in M60. The further internal clean up is needed in other CLs. BUG= 489954 Review-Url: https://codereview.chromium.org/2778983006 Cr-Commit-Position: refs/heads/master@{#471684} [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/CSSPageRule.cpp [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/CSSSelector.cpp [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/CSSSelector.h [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/SelectorFilter.cpp [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/parser/CSSParser.cpp [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/parser/CSSParser.h [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/parser/CSSParserImpl.h [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/parser/CSSParserSelector.h [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp [modify] https://crrev.com/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60/third_party/WebKit/Source/core/dom/StyleEngineTest.cpp
May 15 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2c6439ccb2ec5de9b6986e31f22a49861ee2fa6d commit 2c6439ccb2ec5de9b6986e31f22a49861ee2fa6d Author: hayato <hayato@chromium.org> Date: Mon May 15 09:41:07 2017 Update the deprecation message of /deep/ and remove that of ::shadow This is one of clean up CLs after https://codereview.chromium.org/2778983006. BUG= 489954 Review-Url: https://codereview.chromium.org/2881023002 Cr-Commit-Position: refs/heads/master@{#471711} [modify] https://crrev.com/2c6439ccb2ec5de9b6986e31f22a49861ee2fa6d/third_party/WebKit/LayoutTests/fast/dom/shadow/apply-deep-in-document-scope-expected.txt [modify] https://crrev.com/2c6439ccb2ec5de9b6986e31f22a49861ee2fa6d/third_party/WebKit/LayoutTests/shadow-dom/v0/closed-mode-deep-combinator-and-shadow-pseudo-expected.txt [modify] https://crrev.com/2c6439ccb2ec5de9b6986e31f22a49861ee2fa6d/third_party/WebKit/Source/core/frame/Deprecation.cpp
May 17 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bffed136492ff2507a9b5c5e484dc9229b595dbe commit bffed136492ff2507a9b5c5e484dc9229b595dbe Author: rkc <rkc@chromium.org> Date: Wed May 17 02:46:57 2017 Revert of Make /deep/ as no-op and remove ::shadow in dynamic profile (patchset #9 id:160001 of https://codereview.chromium.org/2778983006/ ) Reason for revert: (from the right account this time) Completely breaks Chrome OS login UI Original issue's description: > Make /deep/ as no-op and remove ::shadow in dynamic profile > > Intent to Remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HX5Y8Ykr5Ns > > To make this CL small one, and easy to be reverted, all tests which depend on /deep/ > (or ::shadow) were either removed or updated in another CL: > https://bugs.chromium.org/p/chromium/issues/detail?id=715034. > > This CL only touched the small part so that users can't use /deep/ or ::shadow > in CSS dynamic profile in M60. The further internal clean up is needed in other CLs. > > BUG= 489954 > > Review-Url: https://codereview.chromium.org/2778983006 > Cr-Commit-Position: refs/heads/master@{#471684} > Committed: https://chromium.googlesource.com/chromium/src/+/a7ab8a110bd6b5339c03a34a5a6bb9a419a49e60 TBR=achuith@chromium.org,alemate@chromium.org,kochi@chromium.org,hayato@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 489954 Review-Url: https://codereview.chromium.org/2885153003 Cr-Commit-Position: refs/heads/master@{#472295} [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/CSSPageRule.cpp [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/CSSSelector.cpp [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/CSSSelector.h [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/SelectorFilter.cpp [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/parser/CSSParser.cpp [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/parser/CSSParser.h [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/parser/CSSParserImpl.h [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/parser/CSSParserSelector.h [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp [modify] https://crrev.com/bffed136492ff2507a9b5c5e484dc9229b595dbe/third_party/WebKit/Source/core/dom/StyleEngineTest.cpp
May 17 2017
,
May 19 2017
,
Jul 10 2017
,
Is there a more precise timeframe for this? We have a couple internal projects that still have some /deep/ and ::shadow references, and were curious when this will land.
Jul 11 2017
,
M60 is still a target. M60 goes stable in 3 weeks. Please see https://bugs.chromium.org/p/chromium/issues/detail?id=723259, which is a blocking issue.
Jul 17 2017
,
Jul 19 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b160073dd51148f56b6586a9902b8a24674886c4 commit b160073dd51148f56b6586a9902b8a24674886c4 Author: Hayato Ito <hayato@chromium.org> Date: Wed Jul 19 04:33:31 2017 Reland: Make /deep/ as no-op and remove ::shadow in dynamic profile Reland the CL [1], which was reverted at [2], since CrOS's OOBE issue was fixed. - [1]: https://codereview.chromium.org/2778983006 - [2]: https://codereview.chromium.org/2885153003 Bug: 489954 , 723259 Change-Id: Ie162502385443a4e9a9cc80444c596458ad1e100 Reviewed-on: https://chromium-review.googlesource.com/575322 Reviewed-by: Takayoshi Kochi <kochi@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/master@{#487745} [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/CSSPageRule.cpp [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/CSSSelector.cpp [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/CSSSelector.h [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/SelectorFilter.cpp [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/parser/CSSParser.cpp [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/parser/CSSParser.h [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/parser/CSSParserImpl.h [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/parser/CSSParserSelector.h [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp [modify] https://crrev.com/b160073dd51148f56b6586a9902b8a24674886c4/third_party/WebKit/Source/core/dom/StyleEngineTest.cpp
Jul 19 2017
,
Let me announce the progress here. - I have just re-landed the removal CL. - Chrome M61 will get it, instead of M60. - I have updated chromestatus too. See https://www.chromestatus.com/feature/4964279606312960. - Chrome Canary gets this removal soon. You can test your sites with Chrome Canary binary. Chrome M61 beta will be available too. - Chrome M61 Stable will be released around early Sep 2017.
Jul 27 2017
,
https://material.io/icons/ is the first site that I found which is broken due to this change (as seen in M61 and M62). It seems like the effects of this change are likely to be quite wide reaching. September is going to be full of carnage :(
Jul 27 2017
,
Hayato: looks like this site uses an old polymer. How was polymer working correctly on other browsers that doesn't support /deep/? Is it doing feature detection for Shadow DOM v0? If so, do we know if the compat impact would be better or worse if we just disabled all of Shadow DOM v0 (including /deep/) at the same time? Ideally we could quickly test sites like this with all of Shadow DOM v0 disabled. Perhaps you want to add a status=experimental RuntimeEnabledFeature for disabling Sahdow DOM v0?
Jul 27 2017
,
rbyers@: you'd break a bunch of Chrom{e,ium} UIs that use Polymer 1, AFAIK, if you disabled Shadow DOM v0. dpapad@/dschuyler@: how is moving to Shadow DOM v1 coming along?
Jul 27 2017
,
> Hayato: looks like this site uses an old polymer. How was polymer working correctly on other browsers that doesn't support /deep/? Is it doing feature detection for Shadow DOM v0? If so, do we know if the compat impact would be better or worse if we just disabled all of Shadow DOM v0 (including /deep/) at the same time? It could be. Disabling Shadow DOM v0 might be better because polyfill can be used everywhere. Polymer folks knows it better than me. @sorvell, if you knows something, please let us know that. > Ideally we could quickly test sites like this with all of Shadow DOM v0 disabled. Perhaps you want to add a status=experimental RuntimeEnabledFeature for disabling Sahdow DOM v0? I can. Let me add RuntimeEnabledFeature to disable Shadow DOM v0.
Jul 27 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/acadbecac0211f2792ba6b67186c65a9ed14b0fa commit acadbecac0211f2792ba6b67186c65a9ed14b0fa Author: Hayato Ito <hayato@chromium.org> Date: Thu Jul 27 16:44:11 2017 Add ShadowDOMV0 runtime flag See https://bugs.chromium.org/p/chromium/issues/detail?id=489954#c68 for the context. Users can disable native Shadow DOM v0 support by adding '--disable-blink-features=ShadowDOMV0' command line switch. Bug: 489954 ,671907 Change-Id: I43a5983fb0794d0c2cd8bf5a1138a80242e47fd1 Reviewed-on: https://chromium-review.googlesource.com/588868 Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Rick Byers <rbyers@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/master@{#489975} [modify] https://crrev.com/acadbecac0211f2792ba6b67186c65a9ed14b0fa/third_party/WebKit/Source/core/dom/Element.idl [modify] https://crrev.com/acadbecac0211f2792ba6b67186c65a9ed14b0fa/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
Jul 27 2017
,
https://material.io/icons/ uses Polymer version 0.5 which is ~3 years old. The current version is 2.0. Polymer 0.5 used Shadow DOM v0 and the /deep/ selector where appropriate. The web components polyfill does feature detection for Shadow DOM to polyfill only if necessary. When necessary, the polyfill shims element css to change /deep/ selectors to specially scoped descendant selectors. I expect the site to function ok on a version of Chrome with Shadow DOM v0 disabled since it works fine on other browsers without Shady DOM v0.
Jul 27 2017
,
@dbeam: Tracking bug for migrating WebUI to Polymer 2 (and therefore shadow DOM v1) is at https://bugs.chromium.org/p/chromium/issues/detail?id=738611. There is lot of work left to do.
Jul 27 2017
,
sorvell: Thank you, that's helpful! hayato: Have you verified that with shadowDOM v0 disabled this particular site does indeed work fine? Do we have reason to believe that old versions of Polymer are the biggest usage of /deep/ on the web? If so, then perhaps we should really be removing /deep/ and createShadowRoot in the same milestone in order to minimize the breakage?
Jul 27 2017
,
sorvell@: what's the behavior when Polymer={shadow:'dom'}? https://cs.chromium.org/chromium/src/ui/webui/resources/js/polymer_config.js?type=cs&q=shadow+dom+polymer_config.js&sq=package:chromium&l=7 Is that a request to use Shadow DOM when it's available? Or a demand?
Jul 27 2017
,
Polymer={dom:'shadow'}**
Jul 27 2017
,
answering my own question: in Polymer 1.x (at least) it's just a request to use shadow https://github.com/Polymer/polymer/blob/1.x/src/lib/settings.html#L35
Jul 28 2017
,
> hayato: Have you verified that with shadowDOM v0 disabled this particular site does indeed work fine? I have verified that https://material.io/icons/ is fixed by '--disable-blink-features=ShadowDOMV0' command line switch. It looks polyfill works well. > Do we have reason to believe that old versions of Polymer are the biggest usage of /deep/ on the web? That's a reasonable guess. I thought the same thing several times, however, the problem is that we don't have any evidence for that. Does someone know any good tools or infrastructure to verify that? > If so, then perhaps we should really be removing /deep/ and createShadowRoot in the same milestone in order to minimize the breakage? Yeah, that is one option we might want to consider, however, I am not confident that it would work well. What I have thought is: - createShadowRoot's usage is still high. We are unlikely to deprecate Shadow DOM v0 soon. People have not started to switch to Shadow DOM v1. - The support of /deep/ is one of the blocking issue for users to switch from Shadow DOM v0 to Shadow DOM v1. - Once we can remove /deep/, we can say: "Please switch to v1", clearly. - The use counter of /deep/ is low enough to deprecate and remove. That is the reason I would like to remove /deep/ at first to reduce the use counter of Shadow DOM v0 so that we can start to deprecate Shadow DOM v0.
Jul 28 2017
,
sorvell@, Is there any Polymer configuration to use polyfill forcefully even if the browser supports Element.createShadowRoot()? If there is no such configuration, I think polyfill can be used if web sites *disable* Shadow DOM v0 *manually* at first before loading Polymer library: e.g. calling "Element.prototype.createShadowRoot = undefined;". That can be used as a workaround.
Jul 28 2017
,
@hayato: Just want to verify that you are not suggesting to run Chromium WebUI Polymer pages with Shady DOM. Is that correct? Per my understanding, for WebUI, using --disable-blink-features=ShadowDOMV0 would be effectively the same as turning off the line at [1], which would break WebUI, since the code depends on using actual Shadow DOM, and would not work with Shady DOM polyfil. [1] https://cs.chromium.org/chromium/src/ui/webui/resources/js/polymer_config.js?l=7
Jul 28 2017
,
hayato@: in addition to looking for things like createShadowRoot(), there are obviously other parts of the API (some of which Chrome depends on). right now, because pretty much all Polymer usage in Chrome is opted into using native Shadow DOM (because we're Chrome-only UI, why not?), there's likely code that assumes this. for example: all paper-ripples add a ripple on touch/mousedown by assuming there's a shadowRoot to append to: https://cs.chromium.org/chromium/src/third_party/polymer/v1_0/components-chromium/paper-ripple/paper-ripple-extracted.js?l=129
Jul 28 2017
,
secondary note: Chrome implements its own paper-ripple :) (this is not Polymer's stock element). and there's probably some Polymer.dom() abstraction that could be used here instead of this.shadowRoot.appendChild() directly, I was just too lazy to figure it out.
Jul 28 2017
,
> Does someone know any good tools or infrastructure to verify that? There are some tools listed at https://www.chromium.org/blink/platform-predictability/compat-tools which could help. Eg. a cluster telemetry run on the top 100k could probably pretty easily tell you what fraction of /deep/ usage on those sites in from polymer. Maybe even HTTP Archive searches would be powerful enough? Unfortunately I don't think builtwith.com has version breakdowns: https://trends.builtwith.com/javascript/Polymer > The use counter of /deep/ is low enough to deprecate and remove. Well, I think that's open to some debate. It's definitely low enough to try, but depending on the severity of breakage we may decide we should rethink the plan. See https://bit.ly/blink-compat for more nuance. > That is the reason I would like to remove /deep/ at first to reduce the use counter of Shadow DOM v0 so that we can start to deprecate Shadow DOM v0. You're the expert here and I trust your judgement. Certainly a few reports from a few sites using ancient versions of Polymer is not enough reason to change course. But we should think of what our backup plan should be if we get lots of complaints from our users of lots of different broken sites. Have you talked to the Polymer team about doing outreach for developers using old versions of their libraries? It could be really valuable in reducing complaints if we had at least a blog post or something saying "if you see the /deep/ warning and your site is broken, upgrade to Polymer 1.0 or add 'Element.prototype.createShadowRoot = undefined' to your site".
Jul 31 2017
,
Let me summarize the timeline so far since I have received similar questions much: - 2015/05: Intent to deprecate: /deep/ and ::shadow [1] - 2015/06: Blink started to deprecate /deep/ (and ::shadow). A deprecation message is: "CONSOLE WARNING: /deep/ combinator is deprecated. See https://www.chromestatus.com/features/6750456638341120 for more details." - 2017/03: Intent to remove: /deep/ and ::shadow. Got 3> LGTMs [2] - 2017/03: Add removal date to console [3], such as: "CONSOLE WARNING: /deep/ combinator is deprecated and will be a no-op in M60, around August 2017. See https://www.chromestatus.com/features/4964279606312960 for more details." - 2017/07: Deferred the removal from M60 to M61, and re-landed the removal CL for M61 [4] [1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/68qSZM5QMRQ/pT2YCqZSomAJ [2] https://groups.google.com/a/chromium.org/d/msg/blink-dev/HX5Y8Ykr5Ns/2Gy1RhZwCQAJ [3] https://codereview.chromium.org/2776073004 [4] https://chromium-review.googlesource.com/c/575322/ Since only 10 days have passed after I re-landed [4], I think we don't get enough feedback. A couple of weeks might be needed until we get more feedback. Basically, we should honor our "Intent to remove" procedure, however, I agree that we should be flexible. Let me prepare to have a backup plan. As far as I know, the following sites are broken on Chrome Canary: - https://material.io/icons/ - One google internal sites Note: I am aware that there are different opinion about this removal. I have heard the following feedback. - Don't remove /deep/ at M61. Our sites will be broken. We don't need enough time to fix it. - It's important to remove /deep/ because it is getting harder and harder to remove it if we do nothing. If we delay the removal further, people are likely to ignore our deprecation/warning message more and more in the future because they happen to think we can change our plan.
Jul 31 2017
,
> Have you talked to the Polymer team about doing outreach for developers using old versions of their libraries? It could be really valuable in reducing complaints if we had at least a blog post or something saying "if you see the /deep/ warning and your site is broken, upgrade to Polymer 1.0 or add 'Element.prototype.createShadowRoot = undefined' to your site". Polymer teams have done a lot of efforts to let old versions users switch to use the latest version so far. I am not sure how they can do additional efforts. @sorvell, if you have any insights about this idea, we really appreciate it.
Jul 31 2017
,
Correction for comment 84: We don't need enough time to fix it -> We don't have enough time to fix it.
Jul 31 2017
,
> @hayato: Just want to verify that you are not suggesting to run Chromium WebUI Polymer pages with Shady DOM. Is that correct? Correct. I am aware that WebUI has a reason to use native Shadow DOM.
Jul 31 2017
,
For whats its worth, this is a very significant change for the small number of users who are affected by this. By design, there's no drop in replacement for this. The apps need to have their UIs fundamentally rewritten if they have used the deep operator for theming. We have a couple of Web Apps which are severely affected by this. Whilst some of the issues are easy to fix. Lots of third party libraries aren't so easy to fix. e.g. https://pub.dartlang.org/packages/bwu_fontawesome_iconset_svg This was the main way to use the Font Awesome icons in Polymer 0.5 web apps. In M61 each icon now has a box about 10 times the size of the original icon. Completely destroying the layout and rendering the app unusable. Like many developers, this landing in Canary was the first time we were aware of the issue. Whilst I know its only a small number of use cases. I think delaying this change a couple more releases would allow users affected by this time to update the affected applications.
Aug 1 2017
,
> For whats its worth, this is a very significant change for the small number of users who are affected by this. +1, we are seeing severe breakages on unstable, and the work needed to workaround this change is non-trivial. Some details: 1) We use Polymer 1.0 2) We use Shadow DOM 3) We have been actively migrating to a modified tech stack that will have the side effect of removing our dependency on /deep/ and ::shadow. This migration started before the deprecation warnings showed a specific date and will not be completed before M61 lands. 4) Not addressing the breakages caused by these changes is a non-starter, as the effects are severe and far-reaching. The aforementioned migration is the #1 priority of the team, but working around these breaking changes is now an even higher priority. We are actively scrambling and pulling people off more important work because of this. At this time, I optimistically hope we can make the M61 deadline, but I'm not certain. I am concerned about the potential for high "severity of breakage" and poor "ease of adaption" due to this change, per the https://bit.ly/blink-compat doc, but I can only speak for the effects on our app.
Aug 1 2017
,
I've prepared a spreadsheet [1]. Please enter a site URL and relevant information directly if you find a site which will be broken at M61. [1] https://docs.google.com/spreadsheets/d/1w2JXdiI7JDSg3GuP-5MqEcmlKauge5WoH6TsV2qIeZY/edit?usp=sharing If a reporter can provide, please also enter a reason why a site owner has not done any action even if we have been showing console deprecation/removal warnings more than 2 years. e.g. Our dev team never see a console in our daily web site development.
Aug 1 2017
,
I have updated the spreadsheet with details of the impact on our PF Platform product. Any idea roughly when the final decision on whether to include this in M61 will be made? We have had to heavily accelerate our work to port the UI to Angular Dart. Completing the port is less work than to remove all the usage of / deep / in the existing and 3rd party libraries. As I mentioned in the spreadsheet, this is an on prem product. So once we have an updated version, coordinating deploying it to all our customers is not trivial.
Aug 2 2017
,
Thank you for the feedback. I think we'll make a final decision around Aug 10. There is a trade-off: An early announcement is better for site owners, but an early decision might not be based on good amount of feedback, I'm afraid. To site owners, given that a few reports from a few sites using ancient versions of Polymer is not enough reason to change course, please please don't be optimistic. Please be prepare for the *worst* scenario for site owners; We'll remove /deep/ at M61 as planned.
Aug 2 2017
,
I've roughly investigated the usage of /deep/ in top 100K sites, using http archive. Query: SELECT page, count(*) FROM [httparchive:har.2017_07_15_chrome_requests_bodies] WHERE REGEXP_MATCH(url, r'\.css$') and REGEXP_MATCH(body, r'/deep/') or REGEXP_MATCH(url, r'\.html$') and REGEXP_MATCH(body, r'<style(\n|.)*/deep/(\n|.)*</style>') GROUP BY page -> Number: 54 54 / 474975 (actual page count) = 0.011%, which is not far from the report of use counter.
Aug 2 2017
,
Aug 3 2017
,
Thanks for considering this. > given that a few reports from a few sites using ancient versions of Polymer To be clear, we are using Polymer 1.0, which is not an "ancient version" of Polymer. Given that there is no recommended migration path, we are currently investing significant amount of time in trying to implement non-trivial workarounds.
Aug 3 2017
,
> To be clear, we are using Polymer 1.0, which is not an "ancient version" of Polymer. Yeah, you are right. I am aware that there are cases where sites use /deep/ intentionally. As you understand, there is no easy migration path for this case. That was exactly one of the reason we, Google, objected to removal of /deep/ at Web Components f2f meeting two years ago. :(
Aug 3 2017
,
> That was exactly one of the reason we, Google, objected to the removal of /deep/ at Web Components f2f meeting two years ago. :( I appreciate that if it didn't make it into the spec, long term it needs to come out. It's just the timing of it that's causing the issues. I know this issue started two years ago, but for most Devs until it lands in Canary, we have no easy way to assess the impact. Particularly with 3rd party libraries which we are unfamiliar with their implementation details. In our case, we had some light usage of deep in our own code (which could be worked around) but the libraries our app depended on are fundamentally broken by this. Hence why the console warnings whilst helpful, are of limited benefit. Just a thought: But with breaking changes known to be hard to fix like this, could you not surface them earlier in Canary? e.g. This shows up in all Canary builds from M60 then the Dev Chanel in M63 and Stable in M64. It would give anyone testing against Canary a lot more notice. I thought I would clarify the impact on our customers: If we don't get a fix developed and deployed before M61 hits Stable. There are going to be several large companies who's staff suddenly find they come into work and can't run the Accounts Payable process (and therefore pay any suppliers). Those companies will have no choice but switch to IE or Firefox as these are critical systems to them. At present, I would say it's 50/50 that update can be rolled out before M61 lands in Stable. Obviously, we will be advising them in advance to try and mitigate the impace. Like wise, I very much doubt there's a single user sitting there saying I can't wait for M61 to land, so I can finally get these Deep Combinators out of my browser! I know our customers don't make a significant portion of your user base, but I am sure others will be similarly affected to varying extents. Ironically we have been recommending our customers use Chrome because it provided the best user experience!
Aug 4 2017
,
Thank you for feedback. I appreciate that. It sounds a general issue for us. That is not specific to this /deep/ case. That could happen on any feature which is used on 3rd party libraries. > Just a thought: But with breaking changes known to be hard to fix like this, could you not surface them earlier in Canary? e.g. This shows up in all Canary builds from M60 then the Dev Chanel in M63 and Stable in M64. It would give anyone testing against Canary a lot more notice. We don't have a such release policy. Canary is used as a next milestone's dev and stable release.
Aug 10 2017
,
Dear web site owners, Let me announce that we've decided to delay the removal of /deep/ from M61 to M63. That means you have additional 3 months. M63 stable will be released around early-mid Dec. I know the removal of /deep/ is super painful for you and us too. e.g. - Polymer team had done tremendous efforts to remove the usage of /deep/ from Polymer. - Supporting both Shadow DOM v0 and Shadow DOM v1 at the same time makes our style and DOM distribution engine super-complex. However, that is what have to overcome, given that we've decided to have Shadow DOM v1, which all browser vendors can agree on implement. We can overcome this painful situation, and I believe we can have a good future; Native Web Components are available in all evergreen browsers. Thank you for your cooperation and giving us precious feedback. Please keep us informed.
Aug 10 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d5d015a62218436871593534dc5bb051aa14b2bc commit d5d015a62218436871593534dc5bb051aa14b2bc Author: Hayato Ito <hayato@chromium.org> Date: Thu Aug 10 08:10:18 2017 Revert "Reland: Make /deep/ as no-op and remove ::shadow in dynamic profile" This reverts commit b160073dd51148f56b6586a9902b8a24674886c4. Reason for revert: We've decided to delay the removal of /deep/ from M61 to M63. See https://bugs.chromium.org/p/chromium/issues/detail?id=489954#c99 for details. Original change's description: > Reland: Make /deep/ as no-op and remove ::shadow in dynamic profile > > Reland the CL [1], which was reverted at [2], since CrOS's OOBE issue was fixed. > > - [1]: https://codereview.chromium.org/2778983006 > - [2]: https://codereview.chromium.org/2885153003 > > Bug: 489954 , 723259 > Change-Id: Ie162502385443a4e9a9cc80444c596458ad1e100 > Reviewed-on: https://chromium-review.googlesource.com/575322 > Reviewed-by: Takayoshi Kochi <kochi@chromium.org> > Commit-Queue: Hayato Ito <hayato@chromium.org> > Cr-Commit-Position: refs/heads/master@{#487745} TBR=kochi@chromium.org,hayato@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 489954 , 723259 Change-Id: I1b58db5bc2f3268f16b832214b87f1d77ada38ee Reviewed-on: https://chromium-review.googlesource.com/609602 Reviewed-by: Hayato Ito <hayato@chromium.org> Reviewed-by: Takayoshi Kochi <kochi@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/master@{#493331} [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/CSSPageRule.cpp [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/CSSSelector.cpp [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/CSSSelector.h [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/SelectorFilter.cpp [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/parser/CSSParser.cpp [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/parser/CSSParser.h [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/parser/CSSParserImpl.h [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/parser/CSSParserSelector.h [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp [modify] https://crrev.com/d5d015a62218436871593534dc5bb051aa14b2bc/third_party/WebKit/Source/core/dom/StyleEngineTest.cpp
Aug 10 2017
,
>Let me announce that we've decided to delay the removal of /deep/ from M61 to M63. >That means you have additional 3 months. M63 stable will be released around early-mid Dec. Thanks for taking on board the feedback from everybody. I know this will really help us and I am sure a lot of the devs affected, prevent any impact on our users.
Aug 10 2017
,
Thank you for the considering the feedback and making this change. As an update, I filed a bug with the Material Icons team, and they were able to workaround the issue. As for our project, we are coming up on 4 eng-weeks of work (two engineers full-time) replacing our /deep/ and ::shadow selectors with alternative approaches. We have replaced ~80% of our selectors, and showstopping problems (i.e. app is unusable) have already been fixed. We are now in the long tail of changes that make the app look ugly but is still technically usable if they aren't addressed.
Aug 15 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6bd1ec4faae8e7df923a87ec799961ee6d3205de commit 6bd1ec4faae8e7df923a87ec799961ee6d3205de Author: Hayato Ito <hayato@chromium.org> Date: Tue Aug 15 10:01:21 2017 Update deprecation/removal message of /deep/ and :shadow We've decided to delay the removal of /deep/ and ::shadow from M61 to M63. See https://bugs.chromium.org/p/chromium/issues/detail?id=489954#c99 for details. Bug: 489954 , 723259 Change-Id: If36e58cf2d3cf7857fb66595c6886bc0be4bf639 Reviewed-on: https://chromium-review.googlesource.com/615207 Reviewed-by: Koji Ishii <kojii@chromium.org> Reviewed-by: Takayoshi Kochi <kochi@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/master@{#494352} [modify] https://crrev.com/6bd1ec4faae8e7df923a87ec799961ee6d3205de/third_party/WebKit/LayoutTests/fast/dom/shadow/apply-deep-in-document-scope-expected.txt [modify] https://crrev.com/6bd1ec4faae8e7df923a87ec799961ee6d3205de/third_party/WebKit/LayoutTests/shadow-dom/v0/closed-mode-deep-combinator-and-shadow-pseudo-expected.txt [modify] https://crrev.com/6bd1ec4faae8e7df923a87ec799961ee6d3205de/third_party/WebKit/Source/core/frame/Deprecation.cpp
Aug 15 2017
,
Labels: Merge-Request-61 I'll go ahead a request for merging r493331 and r494352 (in comment #100 and #103) to M61: - r487745: Revert the removal /deep/ (and ::shadow). - r494352: Update deprecation/removal message for M63. The rationale: See the comment #93. We've decided to delay the removal of /deep/ and ::shadow from M61 to M63. Since 1) the r487745 is the revert of removal of /deep/, and 2) r494352 is just updating deprecation/removal message for M63, accordingly, these merges would be safe enough, I think.
Aug 15 2017
,
Aug 15 2017
,
FWIW I agree with hayato@ that there's a lot of risk to not reverting this from 61. We've gotten multiple independent reports of significant breakage, and we know we tend to get an order of magnitude more complaints about breakage after a removal hits stable. As Chrome's lead for web compat, I believe it's important (and worth some amount of risk) that we take the revert for M61.
Aug 15 2017
,
Thanks! Regarding r494352, it looks like we didn't previously say explicitly "will be removed in M61", just a generic "you should consider to remove it" (further evidence we need to delay removal). So IMHO merging this change to M61 is not critical (though it's also very low risk as nearly a string-only change).
Aug 15 2017
,
Aug 15 2017
,
Aug 16 2017
,
rbyers@, thank you for the comment. govind@, thank you for the approval. Let me merge only r487745 to M61.
Aug 16 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f15b7cd806d666e554ee26fc3b2e7e291f082acb commit f15b7cd806d666e554ee26fc3b2e7e291f082acb Author: Hayato Ito <hayato@chromium.org> Date: Wed Aug 16 03:43:15 2017 Revert "Reland: Make /deep/ as no-op and remove ::shadow in dynamic profile" This reverts commit b160073dd51148f56b6586a9902b8a24674886c4. Reason for revert: We've decided to delay the removal of /deep/ from M61 to M63. See https://bugs.chromium.org/p/chromium/issues/detail?id=489954#c99 for details. Original change's description: > Reland: Make /deep/ as no-op and remove ::shadow in dynamic profile > > Reland the CL [1], which was reverted at [2], since CrOS's OOBE issue was fixed. > > - [1]: https://codereview.chromium.org/2778983006 > - [2]: https://codereview.chromium.org/2885153003 > > Bug: 489954 , 723259 > Change-Id: Ie162502385443a4e9a9cc80444c596458ad1e100 > Reviewed-on: https://chromium-review.googlesource.com/575322 > Reviewed-by: Takayoshi Kochi <kochi@chromium.org> > Commit-Queue: Hayato Ito <hayato@chromium.org> > Cr-Commit-Position: refs/heads/master@{#487745} TBR=hayato@chromium.org, kochi@chromium.org (cherry picked from commit d5d015a62218436871593534dc5bb051aa14b2bc) Bug: 489954 , 723259 Change-Id: I1b58db5bc2f3268f16b832214b87f1d77ada38ee Reviewed-on: https://chromium-review.googlesource.com/609602 Reviewed-by: Hayato Ito <hayato@chromium.org> Reviewed-by: Takayoshi Kochi <kochi@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#493331} Reviewed-on: https://chromium-review.googlesource.com/616502 Cr-Commit-Position: refs/branch-heads/3163@{#597} Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528} [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/CSSPageRule.cpp [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/CSSSelector.cpp [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/CSSSelector.h [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/SelectorFilter.cpp [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/parser/CSSParser.cpp [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/parser/CSSParser.h [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/parser/CSSParserImpl.h [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/parser/CSSParserSelector.h [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp [modify] https://crrev.com/f15b7cd806d666e554ee26fc3b2e7e291f082acb/third_party/WebKit/Source/core/dom/StyleEngineTest.cpp
Aug 16 2017
,
Thank you for merging the revert to M61. Hayato, to make this easier/safer to enable/disable going forward, perhaps you want to put the behavior behind a RuntimeEnabledFeature? Then we can just flip the stable status to easily turn it on and off again?
Aug 17 2017
,
> Hayato, to make this easier/safer to enable/disable going forward, perhaps you want to put the behavior behind a RuntimeEnabledFeature? Then we can just flip the stable status to easily turn it on and off again? Yeah, I was thinking that. In the next time, I'll use the flag.
Aug 18 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/64e1443784843d1d804dbed6d4e1984a1383730d commit 64e1443784843d1d804dbed6d4e1984a1383730d Author: Hayato Ito <hayato@chromium.org> Date: Fri Aug 18 05:56:37 2017 Introduce Runtime flags for /deep/ and ::shadow used in CSS dynamic profile See https://bugs.chromium.org/p/chromium/issues/detail?id=489954#c115 for the context. We'll disable these features at M63. If something is wrong in canary after disabled, we can re-enable these features easily by flipping the flags, without worrying about merge conflicts. Regarding layout tests, we had already removed most of layout tests for /deep/ and ::shadow used in CSS dynamic profile. It might be better to recover some of them, however, that might not be worth doing because I am disabling these features after M62 branch cut, which will happen soon. Site owners can test their sites by adding '--disable-blink-features=DeepCombinatorInCSSDynamicProfile' and/or '--disable-blink-features=ShadowPseudoElementInCSSDynamicProfile' switches. I verified these flags worked correctly with the reported sites in bug 489954 . Bug: 489954 Change-Id: Iea9d4b43576633ad7c1b3935e2576777dcae9826 Reviewed-on: https://chromium-review.googlesource.com/618307 Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Takayoshi Kochi <kochi@chromium.org> Reviewed-by: Bugs Nash <bugsnash@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/master@{#495474} [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/CSSPageRule.cpp [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/CSSSelector.cpp [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/CSSSelector.h [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/SelectorFilter.cpp [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/parser/CSSParser.cpp [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/parser/CSSParser.h [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/parser/CSSParserSelector.h [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/core/dom/StyleEngineTest.cpp [modify] https://crrev.com/64e1443784843d1d804dbed6d4e1984a1383730d/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
Aug 25 2017
,
Sep 5 2017
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0ebd56da93abf970128804390879624b3dc79ac2 commit 0ebd56da93abf970128804390879624b3dc79ac2 Author: Hayato Ito <hayato@chromium.org> Date: Tue Sep 05 05:27:32 2017 Disable runtime flags for /deep/ and ::shadow used in CSS dynamic profile for M63. See https://chromium-review.googlesource.com/c/chromium/src/+/618307 for the context. We'll disable /deep/ and ::shadow at M63. Bug: 489954 Change-Id: If2770da5394b871aa8ea45ed434e23d659e8fc11 Reviewed-on: https://chromium-review.googlesource.com/648369 Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Takayoshi Kochi <kochi@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/master@{#499566} [modify] https://crrev.com/0ebd56da93abf970128804390879624b3dc79ac2/third_party/WebKit/LayoutTests/fast/dom/shadow/apply-deep-in-document-scope-expected.txt [modify] https://crrev.com/0ebd56da93abf970128804390879624b3dc79ac2/third_party/WebKit/LayoutTests/shadow-dom/v0/closed-mode-deep-combinator-and-shadow-pseudo-expected.txt [modify] https://crrev.com/0ebd56da93abf970128804390879624b3dc79ac2/third_party/WebKit/Source/core/frame/Deprecation.cpp [modify] https://crrev.com/0ebd56da93abf970128804390879624b3dc79ac2/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
Sep 15 2017
,
Oct 9
,
Is /deep/ still being removed from JS in m63? A quick test on chromestatus.com shows I'm still able to find nodes within a shadow tree: document.querySelectorAll('html /deep/ chromedash-feature')
Oct 10
,
Let me summarize the status - /deep/ and ::shadow will be removed for *dynamic profile* (styling from CSS) in M63 - /deep/ and ::shadow are still available for *static profile* (querySelector*) for V0 shadow roots (they don't work for V1 shadows) - '>>>' (alternative of /deep/ for Shadow V1) is available under the flag (experimental web platform features) For '>>>' it is being discussed under https://github.com/w3c/webcomponents/issues/78
Oct 10
,
I have no idea what "Shadow-Piercing descendant combinator, '/deep/' (aka '>>>'), and '::shadow' pseudo-element" is. I'm not a programmer, all I know is I'm getting hacked constanly. Michael Sent from MK's iPhone
Dec 11
,
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/860f43550bf6587ca21900dfdf901fce697cbbb7 commit 860f43550bf6587ca21900dfdf901fce697cbbb7 Author: Hayato Ito <hayato@chromium.org> Date: Mon Dec 11 07:03:03 2017 Remove Runtime flags for /deep/ and ::shadow used in CSS dynamic profile M63 stable was released and we've not heard any issue about the removal of /deep/ from any web sites. Let's remove the runtime flags. TBR=haraken Bug: 489954 Change-Id: Ie7831904824e3a08e3e121004bdecabb0871e850 Reviewed-on: https://chromium-review.googlesource.com/818678 Commit-Queue: Hayato Ito <hayato@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Takayoshi Kochi <kochi@chromium.org> Cr-Commit-Position: refs/heads/master@{#523051} [modify] https://crrev.com/860f43550bf6587ca21900dfdf901fce697cbbb7/third_party/WebKit/Source/core/css/CSSSelector.cpp [modify] https://crrev.com/860f43550bf6587ca21900dfdf901fce697cbbb7/third_party/WebKit/Source/core/css/SelectorChecker.cpp [modify] https://crrev.com/860f43550bf6587ca21900dfdf901fce697cbbb7/third_party/WebKit/Source/core/css/StyleEngineTest.cpp [modify] https://crrev.com/860f43550bf6587ca21900dfdf901fce697cbbb7/third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp [modify] https://crrev.com/860f43550bf6587ca21900dfdf901fce697cbbb7/third_party/WebKit/Source/platform/runtime_enabled_features.json5
Dec 12
,
I'm not a programmer, by any means, not even close. I've just been getting hacked badly and I was hoping to get some assistance. I appologize and feel a bit foolish because this stuff reads like completely foreign language to me and I'm sure its something I probably really shouldn't be messing with less I'd wind up worse off than where I'm at... If any of this made a shred of sense I might brave giving it a go but honestly this is all way, way above my head. Although I do really appreciate you taking the time and what appears (to me at least) like a tremendous ammount of effort to help, so for what it's worth... Thanks! Sincerly, M Klemm Sent from MK's iPhone
Dec 12
,
Closing this issue. Two and a half years have passed since we've decided to remove /deep/ from the web, and we've finally done. The /deep/ and ::shadow in CSS dynamic profile (aka style used in *.css files) were removed at M63. M63 stable is rolling out, and we've not heard any issue from web site owners so far. Thank you all for working on this issue. I'd appreciate your understanding and efforts. For remaining tasks, such as cleaning up internal code or making "/deep/" an invalid token in CSS selector, I'll file a separate bug for that.
Dec 12
,
Dec 12
,
Dec 12
,
Filed another bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=794083
Dec 12
,
The devtools when used to connect to a older Chromium (Ver. 44) on Android do not work anymore since Rel. 63 (see https://bugs.chromium.org/p/chromium/issues/detail?id=793814). If i run chrome with the flag --enable-blink-features=DeepCombinatorInCSSDynamicProfile Devtools work again. |
|||||||||||||||||||||||||||||||
►
Sign in to add a comment |
Comment 1 by hayato@chromium.org
, Jun 3 2015