Intent to Deprecate: Shadow-Piercing descendant combinator, '/deep/' (aka '>>>'), and '::shadow' pseudo-element, from the dynamic profile

[Hayato Ito]

Primary eng (and PM) emails

hay...@chromium.org

Summary

Deprecate '/deep'/ (aka '>>>' [1]) and '::shadow' [2] in dynamic profile [3].

Dropping these features is the resolution at Web Components f2f meeting [4].

Compatibility Risk

Medium-Low. No other browser supports these features.

Alternative implementation suggestion for web developers

No direct alternative. There is on-going discussion to make these selectors available in static profile [5].

Usage information from UseCounter

/deep/ -  0.0520% (https://www.chromestatus.com/metrics/feature/timeline/popularity/471)

::shadow - 0.0231% (https://www.chromestatus.com/metrics/feature/timeline/popularity/467)

Entry on chromestatus.com

No.

Entry on crbug.com

https://code.google.com/p/chromium/issues/detail?id=489954

Requesting approval to remove too?

No. I'll be showing a deprecation warning if these selectors are used in the dynamic profile.

[1] http://dev.w3.org/csswg/css-scoping/#deep-combinator

[2] http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement

[3] http://dev.w3.org/csswg/selectors/#dynamic-profile

[4] https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting

[5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591

[Paul Kinlan]

Hi, can you create an entry on chromestatus.com for this deprecation.  It would be nice to have a central place we can keep updated and point people to if they get hit by this issue.

Thanks in advance.

P

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Not required, but LGTM anyway.

[Joe Medley]

+1

Sorry for the delay. I've been sick.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

On Wed, May 20, 2015 at 1:07 AM, 'Paul Kinlan' via blink-dev <blin...@chromium.org> wrote:

[davidlg...@gmail.com]

These selectors are very useful for all the work I have done with Polymer but are absolutely critical for the Atom editor which uses chromium.

Have the Atom guys at github weighed in on this discussion?

For us ignorant to the architecture, what are some of the costs of keeping these in place? (Just curious).

Thanks.

[Elliott Sprehn]

On Sun, Jun 21, 2015 at 7:22 PM, <davidlg...@gmail.com> wrote:

These selectors are very useful for all the work I have done with Polymer but are absolutely critical for the Atom editor which uses chromium.

Can you give some examples of why they're critical?

Have the Atom guys at github weighed in on this discussion?

For us ignorant to the architecture, what are some of the costs of keeping these in place? (Just curious).

There's complexity cost for dealing with knowing what rules match, and how much is invalidated with DOM changes. Once these rules are removed we can also be much more aggressive about sharing styles, for example we could share all the style work we do for every <app-menu> (and the Shadow DOM inside it) in the page.

The style boundary provided by Shadow DOM is good for performance and maintainability, /deep/ and ::shadow defeat the fast path and encourage bad practices.

- E

[tigerh...@gmail.com]

Does this mean that ">>>" will be replacing it, or will this just break existing Polymer 0.5 implementations, which require some shadow-piercing selector for any overrides?

[PhistucK]

The latter.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[max.wa...@intel.com]

I should point out that the UseCounter showed a peak of about 0.45% (ie about ten times more than the sample quoted below), but seems to be in decline (current .15%). ::shadow doesn't seem to have changed much from the quoted sample.

Anyway, I wonder if any consideration is given to use-cases other than web sites. For example, I have chrome apps that use polymer extensively and /deep/ in places. There seems to be quite a few instances in NoFlo-ui too.

[Dominic Cooney]

FWIW I think I have seen DevTools use the /deep/ combinator here: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/devtools.js&q=%5C/deep%5C/&sq=package:chromium&type=cs&l=808

[PhistucK]

Yes, they have used them (but they are in the process of removing them).

☆PhistucK

[Waterman, iMax]

I think it might be a mistake to remove them. They are an important 'last resort' method of changing the style of uncooperative 3rd-party elements that use shadow dom. In my mind, it isn't important that the performance is poor - in fact, it should be poor to 'encourage' the user to find a better alternative (there are plenty of other such "that's slow - don't do that, do it this way instead" things, so I don't see why it's an argument for removing >>> and ::shadow).
The only rationale for removing them is if the web components libraries (eg Polymer) *force* element authors to use methods of exposing styling allowing them to be styled from outside irrespective of if the author wants them to be.

[PhistucK]

As far as I can see, if you take the element and go to its shadow root, you can manipulate the style of whatever you want.

element.shadowRoot.querySelector("div").style.display = "flex";

So it is still possible to change everything, just not with a stylesheet (which means "it is slow, do not do that", but you can still do that, slowly).

☆PhistucK

[Pavel Feldman]

DevTools does not use deep selector as of M45, the code that you see is for opening legacy front-ends while remote debugging. It is fixing the breaking flex min size change. These lines should be removed once blink stops supporting deep.

However, at that point remote debugging of Chrome for Android stops working for non-ToT browsers. The reason is that  we will be opening front-ends from <M45 in the ToT chrome and those rely on deep heavily. We should get the stats on the versions of Chrome for Android we debug remotely, but I'd exect it to affect (break for) most of our remote debugging users.

[Waterman, iMax]

Hrm, there's an argument there, but we'd need to attach it to a mutation observer in order to style dynamically added elements (kind of the essence of css). It'd be cool to get an example documented.

[PhistucK]

Not really, because I believe you can inject stylesheets into the shadow DOM.

☆PhistucK

[Waterman, iMax]

On 16 July 2015 at 12:48, PhistucK <phis...@gmail.com> wrote:

Not really, because I believe you can inject stylesheets into the shadow DOM.

Really? I'd really like to see an example.

Will this method also allow us to inject a style sheet into the shadow dom of an element that is already in a shadow dom?

Thanks,

Max.

[PhistucK]

Yes.

Go to this page, open the console and run this -

var eStyle = document.createElement("style"); eStyle.textContent = "div.boilerplate { color: blue; }" document.querySelector("#ex2bNameTag").shadowRoot.appendChild(eStyle);

The top text ("Hi!"...) will turn blue.

☆PhistucK

[Waterman, iMax]

Care to do an example? ...or even describe the method a bit so I can try it out?

Thanks,

Max.

[PhistucK]

This was an example.

☆PhistucK

[valtid...@gmail.com]

I think it sucks that this has been removed/deprecated, because it allows people to develop independently and share their components and just change the theme from the outside, surely more weight should be given to that, than a usage percentage. most developers still don't know what shadowRoot is all about and that reflects only the percentage of top developers using it without sharing their components and re-using them.

Anyways, here is my proposal of how to overcome the deprecation of this piercing (should work in theory).

<!-- index.html -->
<div>
    -shadowRoot-
        <style> #myid{color: red;} </style>
        <style> @import 'pierce.css' </style>
        <div id="myid">Hello World !!!</div>
</div>

/* pierce.css */

#myid{color: blue;}

This, will give the same result as you would with piercing.

One problem with it maybe that the 'pierce.css' resource may load too late and the page may experience a delayed rendering.

[Günter Zöchbauer]

Any strategy how WebDriver tests should access nested custom elements? All my WebDriver tests will cease to work when /deep/ and ::shadow are removed.

[adenni...@gmail.com]

i am new to all this i have a question i hope you can answer i did not download this or modifie it in anyway i have a problem i did not root my PC i would not know how to. My question is can this stuff be used to get into my e-mails, get my passwords, change, and block, or miss direct my stuff to some other place? If so how can i fix it? I ask because i have been locked out of parts of my computer as well as my cell phone places that i normally have access to? as well all this that i have described above has happened to my phone as well. please if you can help me please text me at 5012763021 or mail me at blaste...@yahoo.com   

[ploo...@gmail.com]

Hi

As much I won't miss /deep/ and ::shadow for styling elements, I'm a little concerned about automatic testing. It may not be exactly related, but how will tools like Selenium WebDriver, WatiR, etc. cope with shadow boundaries? CSS selector with /deep/ seem like a good option to select actual interactive elements, which may be hidden in the shadow DOM. Are there any relevant discussions or other solution?

Thanks,

Tom

[Elliott Sprehn]

On Fri, Sep 18, 2015 at 4:43 AM, <ploo...@gmail.com> wrote:

Hi

As much I won't miss /deep/ and ::shadow for styling elements, I'm a little concerned about automatic testing. It may not be exactly related, but how will tools like Selenium WebDriver, WatiR, etc. cope with shadow boundaries? CSS selector with /deep/ seem like a good option to select actual interactive elements, which may be hidden in the shadow DOM. Are there any relevant discussions or other solution?

Our hope is that these selectors will move to the static profile, so querySelector will still support /deep/. That makes sense, since otherwise you just end up wrapping querySelector in a helper that polyfills /deep/ by traversing .shadowRoot properties.

- E

[346...@monet.k12.ca.us]

ghhddgd

[mark.w...@gmail.com]

Has anybody noticed how the UseCounter has risen drastically in the last month for the /deep/ combinator?

Its usage is currently at around 9%!

[Günter Zöchbauer]

Probably more and more Polymer applications going live.

[ploo...@gmail.com]

And actually a good reason to remove /deep/ before it's too late. Especially that Polymer has better options for styling. That is assuming that Polymer is driving adoption.

[Günter Zöchbauer]

Only if they are already on Polymer 1.x. Previous versions depend on /deep/. 

The Dart port of Polymer 1.x is not even released yet. 

All these apps, people were working on in the last 2 years, are going to break unless they switch to the new Polymer version and rebuild their styling where both might not be trivial tasks.

I'm not concerned for myself. I'm already working on switching to Polymer.dart 1 (release candidate) and I haven't deployed anything yet. 
My concern was about WebDriver but I found workarounds and `querySelector()` will keep support for /deep/ anyway.

[Philip Jägenstedt]

Yikes, that is a serious problem, both because it makes removal pretty much impossible by our regular metrics, and because this will now be causing a great deal of console spam...

Ito-san, what do you make of the situation?

[ploo...@gmail.com]

I understand your concerns. Honestly though, the version 0.5 was called a developer preview for good reason. People should have been expecting big changes somewhere down the road. For what it's worth, there is the 0.5->1.0 migration tool called polyup, which should help to some extent. This may be harsh, but I think that CSS design mistakes made in the past can now be avoided by making the spec more strict thus enforcing good practices

And WebDriver should not be affected, because as I understand it uses the static profile, where /deep/ will remain.

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Günter Zöchbauer

> All these apps, people were working on in the last 2 years, are going to break unless they switch to the new Polymer version and rebuild their styling where both might not be trivial tasks.

This should not always be true. If we remove all of the nonstandard Chrome-specific shadow DOM APIs at once (i.e. we also remove createShadowRoot and friends) then Polymer *should* fall back to the polyfill, just like it does for all other browsers.

It may be the case some sites have not tested in non-Chrome browsers, in which case they could possibly break if they are relying on un-polyfillable parts of shadow DOM. But I would hope that does not happen too often...

[Waterman, iMax]

Is /deep/ and ::shadow part of *Polymer* though? I accepted that Polymer itself would change significantly, but always had the opinion that I could depend on the old version and my code would work. This, however, is a breaking change in the browser which I view as a completely different deal...it essentially breaks code irrespective of if it used Polymer or not.

...or were the implementations of the individual web component features also somehow at version 0.5? If so, that wasn't clear to me at all.

[Waterman, iMax]

I have an app that specifically targets chrome - it's a *chrome extension*. There is no reason to test in other browsers and it had no use for the polyfill, and it *will* break if the APIs are removed, and will break *when* /deep/ and ::shadow are deprecated.

TBH, in my case it's not such a big deal, but please don't think there aren't such cases, and please don't think Polymer is only used on web sites.

Regards,

Max.

[Kenneth Rohde Christiansen]

Max, I assume you are using Polymer? Can't you upgrade the app to 1.0? There are tools for helping doing so

Kenneth

[Waterman, iMax]

On 1 October 2015 at 15:04, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

Max, I assume you are using Polymer? Can't you upgrade the app to 1.0? There are tools for helping doing so

The app uses Polymer 0.5, yes...but, as I said, it isn't really a big deal for this app (for reasons below), but it might be for some. Upgrading often isn't a trivial task, even with polyup (if that's what you're referring to), and that is indeed the case with this app.

The fact is, even though all the dependencies are (effectively) statically linked, because a core feature is deprecated, it will break. It isn't really related to Polymer itself. In my mind, it's a different class of change.

The reason I brought it up was so that a decision can be made one way or another, but including the knowledge that such use-cases are out there, rather than assuming everything is a web site and targeting multiple browsers (and so already use/have a polyfill to fall back on).

The discussion of my app below isn't really important to the discussion, but perhaps it gives some history that is relevant.

For my app, the workarounds for /deep/ and ::shadow are quite plausible (ie applying the style manually using querySelector() with /deep/), but it is extra effort and I've not actually tried yet.

IMO, I would prefer to keep /deep/ and ::shadow and just make them perform terribly so no one uses them - IINM that's pretty much the case anyway - and is it possible that they are only used by Polymer 0.5 users anyway, which aren't going to be using them any more since they're no longer instructed to do so? Perhaps there could be a way to make it simple to enable them again so old apps don't need to do a full port...I dunno.

If you're interested, the app I'm talking about has somewhat fallen by the way-side, and it's become more of a personal project to maintain it (including porting). Much of the difficulty of porting, in my mind, is due to lack of tests (we have some, but they're JS ones, not for components - iinm WCT wasn't around when we started), so it's pretty tricky to be sure all the elements (34 of them) actually behave properly. A lesson learned, for sure.

Of course, the *real* problem is that it isn't possible to upgrade elements one-at-a-time, because you can't have both Polymer 0.5 elements and Polymer 1.0 elements in the same app. If that were possible, then the effort would be much easier to manage - one thing breaks at a time instead of the whole thing at once. It is sort of expected for Polymer 0.5, but it makes me wonder about future versions of Polymer - the promise is that you can 'just include them in your app irrespective of what else you have there', which isn't really true (yet) even with application frameworks, but it is sort of ironic that (iinm) you can combine x-tag elements and Polymer elements, but not Polymer 0.5 elements with Polymer 1.0 elements.

BTW, polyup is only a recent thing, and earlier on it did make quite a mess of code (inserting <head><body> for no reason and duplicating comments, to name but a few) - it is much better now, of course, and lots of bugs fixed and enhancements made, but iinm there's no way to re-run it without throwing away the previous work spent. Perhaps Polylint will help here - I only ran it once recently and it turned up some problems. I could also rerun polyup on a previous '0.5' commit and diff the output, to see what's changed. Some work to do there.

Max.

[todd.k...@gmail.com]

Does this mean https://code.google.com/p/chromium/issues/detail?id=446051 is no longer going to be implemented in chrome as well? 

We use `/deep/` in our internal web app to control a few elements and unfortunately our designer left a few months ago. What are the replacement options for this selector?

[PhistucK]

As far as I know, the intention is to use CSS Custom Properties ("CSS Variables", but not really), currently in development - and already supported in Firefox.

☆PhistucK

On Thu, Oct 1, 2015 at 7:48 PM, <todd.k...@gmail.com> wrote:

Does this mean https://code.google.com/p/chromium/issues/detail?id=446051 is no longer going to be implemented in chrome as well? 

We use `/deep/` in our internal web app to control a few elements and unfortunately our designer left a few months ago. What are the replacement options for this selector?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Todd Kennedy]

It seems a litte strange to deprecate and add a warning when there is yet to be an implemented alternate method to switch to? Is there an issue tracking implemenation of CSS Custom Properties?

[PhistucK]

crbug.com/465126, however, it does not say much. Actually... It does not look like there are any commits for that matter. Levi?

I referred to a CSS based solution. Beside the CSS based solution, there is the JavaScript based one, as I mentioned earlier in the thread -

https://groups.google.com/a/chromium.org/d/msg/blink-dev/68qSZM5QMRQ/Jzrf0eCClZQJ

☆PhistucK

[Levi Weintraub]

Work is ongoing and experimental support is in its late stages of review: https://codereview.chromium.org/1192983003

[Hayato Ito]

I updated the status about a week ago in https://code.google.com/p/chromium/issues/detail?id=489954#c17. That's the latest status as far as I can tell about /deep/.

[Philip Jägenstedt]

Given how high the usage is and that there's no plausible plan for removal, do you think we should just remove the deprecation message?

[PhistucK]

Perhaps, using RAPPOR or whatever, the big users can be found and be evangelized?

☆PhistucK

[PhistucK]

(Or through an internal Google index search)

☆PhistucK

[Dimitri Glazkov]

I don't see how that follows. Can you expand on the reasoning here?

:DG<

[Philip Jägenstedt]

My concern is that deprecation messages will be taken less seriously the more often they are encountered, and 1.5 years ago I removed two deprecation messages with very high usage.

Here are the currently deprecated use counters, sorted by usage:

CSSDeepCombinator: 8.8816%

XMLHttpRequestSynchronousInNonWorkerOutsideBeforeUnload: 1.7753%

PrefixedPerformanceClearResourceTimings: 0.6222%

PrefixedMouseEventMovementY: 0.6013%

PrefixedMouseEventMovementX: 0.6013%

SVGSMILElementInDocument: 0.5650%

PrefixedIndexedDB: 0.3360%

KeyboardEventKeyLocation: 0.1493%

SyncXHRWithCredentials: 0.1351%

PrefixedWindowURL: 0.1076%

PrefixedRequestAnimationFrame: 0.1033%

PrefixedAudioContext: 0.0900%

PrefixedStorageInfo: 0.0764%

LegacyCSSValueMinIntrinsic: 0.0677%

PrefixedPerformanceSetResourceTimingBufferSize: 0.0599%

DeviceOrientationInsecureOrigin: 0.0502%

GeolocationInsecureOrigin: 0.0472%

GetMatchedCSSRules: 0.0434%

SVGSMILAnimationInImageRegardlessOfCache: 0.0406%

DocumentGetCSSCanvasContext: 0.0352%

RangeDetach: 0.0345%

PrefixedCancelAnimationFrame: 0.0279%

DeviceMotionInsecureOrigin: 0.0268%

PrefixedOfflineAudioContext: 0.0124%

LegacyCSSValueIntrinsic: 0.0123%

CSSSelectorPseudoShadow: 0.0121%

PrefixedIDBTransactionConstructor: 0.0115%

PrefixedIDBKeyRangeConstructor: 0.0115%

PrefixedVideoDisplayingFullscreen: 0.0114%

PrefixedIDBRequestConstructor: 0.0111%

PrefixedIDBObjectStoreConstructor: 0.0111%

PrefixedIDBDatabaseConstructor: 0.0111%

PrefixedIDBIndexConstructor: 0.0110%

PrefixedIDBFactoryConstructor: 0.0110%

PrefixedIDBCursorConstructor: 0.0110%

CSSStyleSheetInsertRuleOptionalArg: 0.0107%

CanvasRenderingContext2DCompositeOperationDarker: 0.0104%

PrefixedImageSmoothingEnabled: 0.0103%

EncryptedMediaInsecureOrigin: 0.0100%

PrefixedVideoSupportsFullscreen: 0.0050%

ConsoleTimeline: 0.0049%

XHRProgressEventTotalSize: 0.0044%

XHRProgressEventPosition: 0.0034%

ElementCreateShadowRootMultiple: 0.0026%

ConsoleTimelineEnd: 0.0024%

ConsoleTimelineEnd: 0.0024%

PrefixedCancelRequestAnimationFrame: 0.0023%

PrefixedVideoExitFullScreen: 0.0018%

PrefixedVideoExitFullscreen: 0.0014%

PrefixedVideoEnterFullScreen: 0.0013%

GetUserMediaInsecureOrigin: 0.0011%

PictureSourceSrc: 0.0007%

PrefixedVideoEnterFullscreen: 0.0005%

AudioListenerDopplerFactor: 0.0005%

SVGSVGElementUnsuspendRedraw: 0.0004%

SVGSVGElementSuspendRedraw: 0.0004%

RangeExpand: 0.0002%

AudioListenerSpeedOfSound: 0.0002%

FileError: 0.0001%

ConsoleMarkTimeline: 0.0001%

CanPlayTypeKeySystem: 0.0001%

AudioListenerSetVelocity: 0.0001%

SVGSVGElementUnsuspendRedrawAll: 0.0000%

SVGSVGElementUnsuspendRedrawAll: 0.0000%

SVGSVGElementForceRedraw: 0.0000%

PrefixedMediaGenerateKeyRequest: 0.0000%

PrefixedMediaCancelKeyRequest: 0.0000%

PrefixedMediaAddKey: 0.0000%

NodeIteratorDetach: 0.0000%

ElementCreateShadowRootMultipleWithUserAgentShadowRoot: 0.0000%

ElementCreateShadowRootMultipleWithUserAgentShadowRoot: 0.0000%

I don't think we need to have a hard threshold or anything, but when usage is as high as for /deep/, we should consider the balance of developers promted to stop using the feature vs. developers conditioned to ignore deprecation messages.

More concretely, what is the plan for /deep/ now that usage has soared?

Philip

[Hayato Ito]

Blink deprecated /deep/ in M45 about a month ago. We might want to wait for another couple of months to decide something.

[Günter Zöchbauer]

Talk to the Polymer guys to remove it everywhere in Polymer 1.x, or at least add deprecation notices and remove it later. 

There are still styles containing /deep/ shipped with the current Polymer and elements versions. 

I'm pretty sure if they remove it, usage will get down notably. 

Mit freundlichen Grüßen

Günter Zöchbauer
gue...@gzoechbauer.com
+43 (699) 10 18 87 15

[masatak...@gmail.com]

I'm not sure if that rise in usage is trustworthy or not.

Looking at the graph [1] usage has drastically risen up after September 2 or 3.

The day is right after Stable got M45, which includes the deprecation warning along with the change in UseCounter [2].

The graph also shows a slight bump up in June 12, a few days after the commit landed in blink. And that is the day after Chrome dev (M45) release with the blink including the change [3].

I mean, isn't there a bug in UseCounter or SelectorChecker which caused such usage increase in short time?

If that were because some new Polymer apps, there should've been some usage increase in other Shadowy selectors (like ::shadow or ::host) as well. I don't see such in chromestatus.com [4][5][6]

[1] https://www.chromestatus.com/metrics/feature/timeline/popularity/471

[2] https://chromium.googlesource.com/chromium/src/+/d6fe1382b2%5E%21/#F20

[3] http://googlechromereleases.blogspot.jp/2015/06/dev-channel-update_11.html

[4] https://www.chromestatus.com/metrics/feature/timeline/popularity/468

[5] https://www.chromestatus.com/metrics/feature/timeline/popularity/469

[6] https://www.chromestatus.com/metrics/feature/timeline/popularity/470

[Philip Jägenstedt]

You're right, what happened is that at the same time that
CSSDeepCombinator was deprecated, the method of counting was also
changed:
https://codereview.chromium.org/1166833002

The change was in M45, and when that reached stable the usage appeared
to increase. Why is the difference between the old and new accounting
so large? CSSSelectorPseudoShadow was also changed similarly, but that
didn't make any difference in the recorded usage:
https://www.chromestatus.com/metrics/feature/timeline/popularity/467

(I'm hoping that there's a bug here and that usage is actually much lower.)

[Rune Lillesveen]

On Tue, Oct 6, 2015 at 2:04 PM, Philip Jägenstedt <phi...@opera.com> wrote:
> You're right, what happened is that at the same time that
> CSSDeepCombinator was deprecated, the method of counting was also
> changed:
> https://codereview.chromium.org/1166833002
>
> The change was in M45, and when that reached stable the usage appeared
> to increase. Why is the difference between the old and new accounting
> so large? CSSSelectorPseudoShadow was also changed similarly, but that
> didn't make any difference in the recorded usage:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/467
>
> (I'm hoping that there's a bug here and that usage is actually much lower.)

I added a printf in SelectorChecker where we count /deep/, and it
triggered on chrome://settings, chrome://downloads, etc. Is that
expected?

--
Rune Lillesveen

[pbu...@gmail.com]

I am an Angular newbie. How to fix this issue?
I have a pre-existing website that presents the error.  What is the alternative code or graceful degradation for this?

[PhistucK]

To avoid this warning completely, you have to access the shadow root using JavaScript and change whatever you want there.

☆PhistucK

On Tue, Oct 13, 2015 at 4:50 AM, <pbu...@gmail.com> wrote:

I am an Angular newbie. How to fix this issue?
I have a pre-existing website that presents the error.  What is the alternative code or graceful degradation for this?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

I see that the no-internet-or-network-error page uses /deep/ in Chrome 45. This may explain the spike.

It does not use it anymore in the latest code, though, so the usage may descend once this version of the code becomes stable.

Example (at least in my currently firewalled network) -

https://144.talkgadget.google.com/talkgadget/d?token=d

Press F12 and you will see the warning.

☆PhistucK

[tho...@thomashigginbotham.com]

I just learned about /deep/ recently through answers on StackOverflow and other resources. I was glad to have found it, because it solved a big problem I was having: how to provide default styles for things like font color, backgrounds, margins, etc. from outside of a component. I realize that it's possible to use variables inside a component to allow outside manipulation, but to expect a component author to anticipate everything the consumer may want to change doesn't seem reasonable.

I may be missing something, but as of now, I'm not aware of any alternatives to /deep/ and ::shadow that address this issue. I hope I'm wrong. Here's a JSFiddle to illustrate the problem: https://jsfiddle.net/02tvrhsv/

[PhistucK]

By the way - the spike is now gone. I guess it was the error page. The numbers are still a bit high (0.2), but they are still descending. Once Chrome 46 takes full control and Chrome 47 is out, I guess it will go even farther down.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[williamfr...@gmail.com]

Looking for help.  My asus chromebook will not connect to home wifi.  It will connect to other wifis, also all other devices in home will connect.  I was looking at the network error and see the following:  /deep/ combinator is deprecated.  See https//www.chromestatus.com/features/6750456638341120 for more details. I looked that up and followed to this site.  Very frustrated that I can't get my chromebook online at home. Any advice on what I can do to fix this bug???  mston...@yahoo.com

[PhistucK]

The console error has nothing to do with your issue, it is a web development detail that does not influence your connection in any way.

Use https://productforums.google.com/forum/#!forum/chromebook-central instead.

☆PhistucK

[guilherm...@gmail.com]

I just learned about /deep/ recently through answers on StackOverflow and other resources. I was glad to have found it, because it solved a big problem I was having: how to provide default styles for things like font color, backgrounds, margins, etc. from outside of a component. I realize that it's possible to use variables inside a component to allow outside manipulation, but to expect a component author to anticipate everything the consumer may want to change doesn't seem reasonable.

I share the same concerns that Thomas and some others pointed out. For me, one of the most killing features of the whole Web Components spec is the encapsulation of our components. Nothing we write inside them affects the external page and the page does not interfere with component behavior and styling -- only if explictly wanted.

Think about web development as we know today. We have a lot of open source going on, various components with specific behaviors for us to use. Let's use jQuery plugins as an example. We all have used them. And we all had the need to customize theirs styles. Imagine a neat multiselect plugin implemented on Web Components technologies (no CSS class namespacing, using Shadow DOM, etc). Even having a beautiful style, it may not fit in my website, I could have a totally different design guideline than the one used by the component. Should the developer expose every single style property for me to override? background-color, color, display (inline, block, ...), line-height... and the list only grows -- especially because we would have these options for the select box and the select options. Is it really how we should handle the customizations? Browsers don't expose variables to style a <select> element.

About adding style blocks into shadow roots programmatically... just no! Did you visualize about the day-to-day usage of this? How we could use this to customize all of our custom elements? If I have 3 multiselects, 1 modal and other custom, totally independent components, I'll have to add the styles to every single one of them by hand? If I dynamically add a component to my web page, won't it match my website styles "by default"?

Maybe I am seeing all the Web Components proposal wrong, but wasn't it idealized to be easier to create... er... web components? Reusable, independent, "composable", behavior-specific and customizable components? Please don't use only current usage statistics to base the decision to remove the selectors -- use theirs real utility instead.

[Hayato Ito]

Thank you for the feedbacks.

I am feeling that some of the comments in this thread are not specific to Blink. We might want to discuss this kind of topics from the view points of Web Components Standards.

It might be better to raise your concerns in more appropriate places, such as GitHub's Web Component issues [1], so that your concerns will get much attentions from other browser vendors too.

AFAIK, the following two topics are relevant:

- https://github.com/w3c/webcomponents/issues/78

- https://github.com/w3c/webcomponents/issues/300

[1]: https://github.com/w3c/webcomponents/issues/

[ivebeen...@gmail.com]

I have the same sort of problem.

I am making a Gantt Chart and wish for classes to style a div inside of my component

https://jsfiddle.net/cnxemajr/1/ (forked from previous demo).

I wish to either "defer" the styles to the shadow div (i.e if I put a "background-color" on the component, the style is applied to the "div" in the shadow root) or use deep CSS to add more colours to my gantt chart. The margins inside the component are automatically adjusted based on the start/end attributes.

Full code: https://github.com/ivebeenlinuxed/HTML5Gantt

Current Styling: https://github.com/ivebeenlinuxed/HTML5Gantt/blob/master/test.html#L70

[nhunh]

Vào 18:52:36 UTC-7 Thứ Ba, ngày 19 tháng 5 năm 2015, Hayato Ito đã viết:

[thaivan...@gmail.com]

Vào 08:52:36 UTC+7 Thứ Tư, ngày 20 tháng 5 năm 2015, Hayato Ito đã viết:

[forsights...@gmail.com]

Hi, I am so incredibly frustrated with all of the bugs that seem to come my way. I have ZERO idea on how to fix this in Chrome. The attached is what happens when I sign in as guest. It is different when I log in as Forsight. Due to the effects of the bugs over the last few years, I have had to save them on drives or write them out. They have also depreciated google hangouts on my android. Any help on how to fix this would be great. 

Also does anyone know what fs_notifymark, means? (Second attachment)

Thank you in advance.

Mary

On Wednesday, May 20, 2015 at 4:07:43 AM UTC-4, Paul Kinlan wrote:

Hi, can you create an entry on chromestatus.com for this deprecation.  It would be nice to have a central place we can keep updated and point people to if they get hit by this issue.

Thanks in advance.

P

[Hayato Ito]

Regarding with the warning message about /deep/ combinator in the chrome://settings/,

I've filed a bug here: https://code.google.com/p/chromium/issues/detail?id=585677

[Christian Biesinger]

While it's true that we should fix the bug about the deprecated deep
selector, I am not sure I understand how this affects you. This only
shows up if you use the inspector to inspect Chrome's settings page,
right? Is there something else that you see? How is Hangouts on
Android related, and why do you say it's deprecated?

I didn't see fs_notifymark in the second screenshot. But as far as I
can tell that's just a kernel thread (actually called fsnotify_mark).
Why do you ask?

-Christian

[olgar...@yahoo.gr]

this really sucks!Does anyone have any removal tool to get rid of?only problems causes!i dont speak japanese-chinese(whatever)

[PhistucK]

What are you talking about?

☆PhistucK

On Fri, Mar 4, 2016 at 8:23 AM, <olgar...@yahoo.gr> wrote:

this really sucks!Does anyone have any removal tool to get rid of?only problems causes!i dont speak japanese-chinese(whatever)

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

[lostat...@gmail.com]

just curious  iC333 and was wondering what GHost it was.

[ivanp...@gmail.com]

[anan...@gmail.com]

Hi, I'm confused as to whether this is resolvable or not. I received the warning "/deep/ combinator is deprecated." I want to know if this is a bad thing, and if so, how to resolve it (If possible). Thanks!

On Tuesday, May 19, 2015 at 9:52:36 PM UTC-4, Hayato Ito wrote:

[PhistucK]

This is a "bad" thing, yes. You should avoid it. If the offending code is included in a library, try updating the library. If it is your code, switch to using JavaScript for what it currently does in CSS.

☆PhistucK

[PhistucK]

To clarify, I did not mean that you should use /deep/ (or >>> or whatever) in JavaScript. I meant that you should find a way in JavaScript, without them, to get to the elements you need (using element.shadowRoot.querySelector(...), for example, to cross shadow boundaries).

I am not sure /deep/ and similar will be supported across browsers even in querySelector, which is why I am clarifying.

☆PhistucK

[Anand Beh]

Is there any way I can solve this problem? I don't know how to code, sorry. I was wondering if there was an easy way to fix this without using "element.shadowRoot.querySelector." I don't know Java script :/

[Todd Kennedy]

Its also disappointing that no css solution exists requiring us to refactor our app to handle it on the code end. 

Then again our fault for using a non standard i guess...

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/68qSZM5QMRQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

[PhistucK]

Not that I know.

☆PhistucK

[shj...@gmail.com]

[rustyco...@gmail.com]

[nadir.s...@gmail.com]

I find that in component sets like a tabgroup and its tabs or a stepper and the stepper headers where say the wrapping <x-stepper> and a <x-stepper-tab> inside its shadow dom, where the custom elements are technically isolated shadow doms but are part of the same library and directly related, having ::shadow ends up really helpful for making small but important tweaks in situations like minor differences needed when the tab is the first item in the list.

In these situations, losing ::shadow is going to mean code getting a lot messier with the code getting more complex to do the same thing and gaining no actual isolation/compartmentalization benefits because these components are directly related to each other and no-one outside those bounds needs to interact with whatever the component is going to have to add to make these tewaks.

[vrpn...@gmail.com]

[Shane Stephens]

An update on /deep/:

Usage of /deep/ has continued to trend downwards, and is currently hovering somewhere just above 0.05% of page loads. As such, /deep/ is still too commonly used to be considered for removal. However, from discussion with the Polymer team, it's clear that much of the /deep/ usage is due to legacy CSS that's being pulled into Polymer pages.

Furthermore, most of those pages are currently using the shady DOM shim rather than native shadow DOM (on Polymer 1.0 you need to opt into using shadow DOM and most pages don't). When using this shim, the /deep/ rules are rewritten, and although they remain on the page they have no impact.

To assess how much genuine usage of /deep/ is in the wild, I added a new use counter (CSSDeepCombinatorAndShadow) that only triggers when a page both contains CSS rules with the /deep/ combinator and shadow DOM. It's recently been activated on stable and is reporting about 0.0062% of pages use both features together.

Another way of looking at this is that without shadow DOM on a page, the /deep/ combinator acts exactly like the descendant combinator - this use counter suggests that there's an upper limit of 0.0062% of page views that would be impacted if we switched the /deep/ combinator to just alias the descendant combinator.

So I'd like to suggest that we consider removing /deep/ by replacing its implementation with the descendant combinator (when using the dynamic profile) for now, and that we continue to monitor usage so that we can remove it entirely from the dynamic profile at some point in the future.

Thoughts?

Sincerely,

    -Shane Stephens

[Takayoshi Kochi]

Sounds like a good step forward to deprecate /deep/ in dynamic profile.

I also have a plan to *allow* one in static profile (e.g. used in querySelector() and friends in scripts),

but only with the new '>>>' syntax.

https://bugs.chromium.org/p/chromium/issues/detail?id=633007

--

Takayoshi Kochi

[PhistucK]

I seem to recall seeing the warning on chrome:// pages recently. Are those counted as well (and why are they still there...)?

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Takayoshi Kochi]

On Fri, Aug 5, 2016 at 4:13 PM, PhistucK <phis...@gmail.com> wrote:

I seem to recall seeing the warning on chrome:// pages recently. Are those counted as well (and why are they still there...)?

That one is tracked at https://bugs.chromium.org/p/chromium/issues/detail?id=498405

--

Takayoshi Kochi

[PhistucK]

Yes, well, this is open for over a year and it affects the numbers. Not cool. :(

☆PhistucK

[lyonsjr...@gmail.com]

can someone help me with this my email is lyonsjr...@gmail.com

/deep/ combinator is deprecated. See https://www.chromestatus.com/features/6750456638341120 for more details.

VM59 list_selection_controller.js:224'KeyboardEvent.keyIdentifier' is deprecated and will be removed in M53, around September 2016. See https://www.chromestatus.com/features/5316065118650368 for more details.

[PhistucK]

For /deep/, you are probably using old version of Polymer, or of certain Polymer based elements. Update them.​

For KeyboardEvent.keyIdentifier, search your code for keyIdentifier and replace it with more standard methods.

Anyway, please, use stackoverflow.com for help with these in your specific cases.

☆PhistucK

[myange...@gmail.com]

Hey Hayato, get out of my computer. You are a hacker and I can reveal mur identity

[myange...@gmail.com]

First of all Hayat get off my computer. She is a hacker that has completely taken over my computer. I can reveal her identity biz she is my husbands girlfriend

[PhistucK]

Hayato is a Chrome engineer. You are subscribed to blink-dev.

If you want to unsubscribe and stop getting those e-mails -

Try sending a blank e-mail to blink-dev+...@chromium.org (note that +unsubscribe in the address, it is important). If you already did exactly that, skip this.

If that does not work and you are still getting e-mails -

1. Go to https://groups.google.com/a/chromium.org/forum/m/#!forum/blink-dev.

2. Click on the button that has an icon of a head and shoulders.

3. Click on "Leave group" and you are done. Or -

 a. Select in the selection box - "Don't send email updates".

 b. Click on "Save".

☆PhistucK

[gospe...@gmail.com]

[prona...@gmail.com]

On Tuesday, May 19, 2015 at 6:52:36 PM UTC-7, Hayato Ito wrote:

[sidhar...@synerzip.com]

In the example jsfiddle, there are two div with id 'outer1' and 'outer2'. Each div has span element in its shadow dom.

The style element in <head> contains css rules for each span. 

As you can see, for outer2, the style is not applied because the css rule doesn't have /deep/ combinator. In this case, solution is to copy the style element and keep it within shadow root of div with id 'outer2'. 

The only problem with that approach is if I have large number of such divs. I will have to copy the style element for each div making dom heavy. 

Is there a better solution available?

[PhistucK]

CSS variables (custom properties) should help in this case, right?

☆PhistucK

This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

[Elliott Sprehn]

Also I'm not sure what you mean by make the DOM heavy, put a <style> element inside each ShadowRoot with the styles specific to that one. You're better with two small sheets in that case instead of one.

[sidhar...@synerzip.com]

In our app, the style and data comes at different time. So CSS custom properties does not help in this case.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[sidhar...@synerzip.com]

I have a worst case where a div can repeat 500 times and the style for shadow element are all same. So then I have to copy the same style element for each div inside shadow dom.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

CSS custom properties have an API for dynamic manipulation, as far as I know. Do they still not help?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.