Intent to deprecate is here:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/68qSZM5QMRQ/pT2YCqZSomAJ

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

Hello, when are you planning to stop supporting '/deep/'?
I'm asking because removing '/deep/' will break several Chromium and Chromium OS Web UIs. 

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.

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!!

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/

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

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

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

FYI. The spec discussion is here: https://github.com/w3c/webcomponents/issues/78

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

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.

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?

Good bye to DevTools' custom themes :(

Now getting deprecation warning in MeteorJS 1.2.0.1 (Latest Stable) [1]

[1] https://www.meteor.com/

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

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

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/

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

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?

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

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

+shans@

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

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': https://bugs.chromium.org/p/chromium/issues/detail?id=568218#c16.  Thoughts?

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.

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.

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.

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

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>

to

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

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


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?

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.

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

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

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

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

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

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. 

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.

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

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.