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.

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

	Screen Shot 2017-07-26 at 9.28.27 PM.png 37.7 KB View Download

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?

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?

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

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

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.

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

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?

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?

Polymer={dom:'shadow'}**

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

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

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. 

@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

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

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.

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

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.

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

Correction for comment 84: We don't need enough time to fix it -> We don't have enough time to fix it.

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

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.

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

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.

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. 

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.

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.

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.

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

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

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.

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.

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

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

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.

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

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.

r487745: how safe is the revert?
r494352 is not yet baked in Canary,landed in trunk 7 hrs back. Please update the bug with Canary result.

Based on comment #104 and answers for above, we might take these merges in for M61 if fully safe. What do you think +abdulsyed@?.

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.

r487745: Ok, will take revert in for M61. Please wait for approval.
r494352: will wait for canary result. How important is this change for M61?

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

Approving merge for r487745.

Rejecting merge r494352 based on comment #108. 

Note: Please only merge r487745 to M61.

Please only merge r487745 to M61.

rbyers@, thank you for the comment.
govind@, thank you for the approval. Let me merge only r487745 to M61.

Correction: I meant r493331, instead of r487745 (which is the original CL r493331 reverted).

I think everyone understand the context correctly. So let me merge r493331.

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

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?

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

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

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

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

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

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

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

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

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.

Filed another bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=794083

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.