Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 489954 Remove Shadow-Piercing descendant combinator, '/deep/' (aka '>>>'), and '::shadow' pseudo-element
Starred by 58 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 715034
issue 682295

Hotlists containing this issue:

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.
Blockedon: 632009
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 and 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.
Blockedon: -632009
/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.

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.
these are the files you might still have problems with

$ git grep -l 'i18n-content' -- chrome/browser/resources/ | xargs grep -l polymer

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 &nbsp; inside the shadow roots they care about) to remove /deep/.
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.
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>


  <div i18n-content=blah>&nbsp;</div>

which is really all the CSS was doing anything (through content:).

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):

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.

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.
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".


> 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?
I think what shans@ meant was:

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.
Sounds great, looking forward to the intent-to-remove discussion!
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.

Thank you kochi@ and shans@.
As we chatted offline, we are going to send an "Intent to remove".
Here is the "Intent to Remove" thread in blink-dev:

See also chromestatus entry: Make /deep/ behave like the descendant combinator " ":
Project Member Comment 52 by, Mar 29
The following revision refers to this bug:

commit efa081e7cade69a78de92f0548ad80d440cec7e6
Author: hayato <>
Date: Wed Mar 29 07:07:18 2017

Add removal date to ::shadow and /deep/

Intent to Remove:!topic/blink-dev/HX5Y8Ykr5Ns


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


Comment 53 by, Today (16 hours ago)
Blockedon: 715034
Sign in to add a comment