Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 489954 Remove Shadow-Piercing descendant combinator, '/deep/' (aka '>>>'), and '::shadow' pseudo-element
Starred by 56 users Project Member Reported by, May 20 2015 Back to list
Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on: View detail
issue 498405
issue 682295

Sign in to add a comment
Dropping 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.

Project Member Comment 2 by, Jun 4 2015
The following revision refers to this bug:

r196442 | | 2015-06-04T01:03:47.394773Z

Changed paths:

Add a deprecation message for shadow-piercing descendant combinators and shadow pseudo elements.

Deprecate /deep/ and '::shadow'.

"Intent to Deprecate" is here:!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.


Review URL:
Hello, when are you planning to stop supporting '/deep/'?
I'm asking because removing '/deep/' will break several Chromium and Chromium OS Web UIs. 
Comment 4 by, 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:
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.
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!!
Comment 6 by, 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 [3] ML is a good place to raise such a request.  Would you be willing to give us a feedback there?

No, /deep/ and friends are still valid in querySelector.  They're being removed from the "dynamic" profile, but kept in the "static".
#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)
Comment 9 by, Jul 14 2015
I have a plan to remove deprecation warning from the static profile.

I've explained it in this CL's description:
FYI. The spec discussion is here:
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?? --
Varunkumar.N say your common styles are in a file called


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.
Comment 13 by Deleted ...@, 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?
Comment 14 by, Sep 17 2015
Good bye to DevTools' custom themes :(
Now getting deprecation warning in MeteorJS (Latest Stable) [1]

Labels: Hotlist-Recharge
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!

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.


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.

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!

Summary: Remove Shadow-Piercing descendant combinator, '/deep/' (aka '>>>'), and '::shadow' pseudo-element (was: Remove Shadow-Piercing descendant combinator, '/deep/' (aka '>>>'), and '::shadow' pseudo-element, from the dynamic profile)
Comment 21 Deleted
Comment 22 Deleted
Comment 23 by Deleted ...@, 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?
Comment 24 by Deleted ...@, 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
 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 
how do you remove it? i dont even know what i done please help me.....
Project Member Comment 27 by, May 19 2016
The following revision refers to this bug:

commit 1b0aab34b5ef9e168f1627703da1cc07c092ab62
Author: shans <>
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.


Cr-Commit-Position: refs/heads/master@{#394640}


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:

Components: -Blink>WebComponents Blink>DOM>ShadowDOM
Comment 31 Deleted
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.
Note that instead of removing the warning, we could just consider downgrading it to a 'violation':  Thoughts?
Blockedon: 682295
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.
Blockedon: 498405
Hmm. That might make sense. However, can we defer the decision until 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.
Sign in to add a comment