Intent to Ship: Shadow DOM v1

Skip to first unread message

Hayato Ito

Jun 23, 2016, 2:55:03 AM6/23/16
to blink-dev
Contact emails

Most parts of the Shadow DOM specification have already been upstream-ed to the following Web Standards, including, but not limited to:
  • DOM Standard: 3 Events, 4.2.2 Shadow tree, 4.2.3 Mutation Algorithms, 4.2.5 Mixin DocumentOrShadowRoot, 4.2.9 Mixin Slotable, and so on
  • HTML Standard: 4.12.4 The slot element, and others.
  • CSS Scoping: 3 Shadow Encapsulation (Shadow DOM and Selectors, Shadow Tree and the Cascade, Flattening the DOM into an Element Tree and so on)
Upstreaming is on going.

Ship Shadow DOM v1. Please see "What's new in Shadow DOM v1 (by examples)" for new Web-facing APIs and the difference between v0 and v1.

Link to “Intent to Implement” blink-dev discussion
See also the status update mail which I sent to blink-dev on March.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Demo Link

DevTools shows a shadow root v1, as well as v0, including its mode (open/closed).

Interoperability risk
For a better interoperability, I have started upstreaming Blink's Shadow DOM Tests to W3C Web Platform Tests. Apple had shared their tests too.
As of now, Blink passes 169 tests out of 171 tests. The two failing tests are well-known issues, which have also been failing on v0, tracked in here.

Blink's initial implementation will not ship "Slots in a flat tree" feature (w3c/webcomponents#308). This feature depends on "display: content", which Blink will implement after LayoutNG is completed. That will not happen soon.

The followings are remaining specification issues with v1. We are working on addressing them with the cooperation with other browser vendors. They would not be a blocking issue to ship v1.
Compatibility Risk
This is NOT an "Intent to deprecate: Shadow DOM v0". I will not deprecate Shadow DOM v0 at the timing of shipping v1.

I did the best efforts to make Shadow DOM v1 live together with Shadow DOM v0 within one document without any breakage. They can co-exist in Blink.

Deprecation plan for v0: Shadow DOM v0 will be deprecated separately. I will send an "Intent to deprecate: Shadow DOM v0" when I can feel it is ready to deprecate. As of now, we do not have a clear ETA. Shipping v1 is the most effective way to decrease the usage counter of Shadow DOM v0, I think.

For reference, here is the summary of the relevant use counters:
OWP launch tracking bug

Entry on the feature dashboard

Jochen Eisinger

Jun 23, 2016, 3:08:49 AM6/23/16
to Hayato Ito, blink-dev


Jun 23, 2016, 3:24:31 AM6/23/16
to Jochen Eisinger, Hayato Ito, blink-dev
How much interoperable between Blink and WebKit?  Does the main feature of Shadow DOM (attachShadow API, and basic slotting behavior?) work well in both?

Software Engineer, Google

Hayato Ito

Jun 23, 2016, 3:55:49 AM6/23/16
to TAMURA, Kent, Jochen Eisinger, blink-dev
As far as I can test Safari Technology Preview (released on June 22, 2016), using W3C Web Platform Tests (, most of main feature of Shadow DOM work well also in Safari Technology Preview. It is not perfect, but we are getting better and better.

The problem is that the coverage of W3C Web Platform Tests for Shadow DOM v1 is not so high. It would be nice for us to upstream our tests more and more. Let me continue contributing to W3C Tests for better interoperability.


Jun 23, 2016, 4:11:35 AM6/23/16
to Hayato Ito, Jochen Eisinger, blink-dev
It sounds good.  LGTM2 to ship.

Jun 23, 2016, 5:20:01 AM6/23/16
to blink-dev
  • The followings are already deprecated, but not removed from Blink yet:

Out of interest when web testing and wanting to select an element deep in the bowels of multiple layers of ShadowDOM, what is the recommended approach if /deep/ is deprecated?


Hayato Ito

Jun 23, 2016, 5:57:35 AM6/23/16
to, blink-dev
You might be interested in issue #354: Did you have a chance to look at #354 and comment there?

Mark Charsley

Jun 23, 2016, 6:50:59 AM6/23/16
to Hayato Ito, blink-dev
That's a rather long email trail, and I'm far from an expert (despite having added shadow DOM v0 support to chromedriver), and I'm not sure of how much of internal Google testing frameworks I can discuss in a global list...

But from what I've seen the ability to select an element arbitrary numbers of shadow DOM layers down with a single CSS selector is a very valuable thing when it comes to webtests. If you remove /deep/ support then code like this

will go from a simple one-liner to a tedious function that looks for shadowDOM1, cracks it open, looks for shadowDOM2 inside that, cracks that open, looks for shadowDOM3 inside that, cracks that open and then finally finds the element you're interested in (a function that will break each time you re-arrange your layers for shadow DOM). Or even worse - if I understand that thread correctly - not being able to select the element at all, because the shadow DOM is "closed".

Having a command-line flag to the browser that webdriver uses when starting it up that says "allow /deep/ to work within selectors", and isn't set by default would be a reasonable compromise.


Alex Russell

Jun 23, 2016, 1:43:01 PM6/23/16
to TAMURA, Kent, Hayato Ito, Jochen Eisinger, blink-dev

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

Dimitri Glazkov

Jun 23, 2016, 1:43:37 PM6/23/16
to Alex Russell, TAMURA, Kent, Hayato Ito, Jochen Eisinger, blink-dev


Elliott Sprehn

Jun 23, 2016, 1:50:32 PM6/23/16
to Mark Charsley, Hayato Ito, blink-dev

Fwiw I think we should keep /deep/ in the static css profile. :) The alternative of what authors will write is far far worse.

Hayato Ito

Jun 23, 2016, 9:57:35 PM6/23/16
to Elliott Sprehn, Mark Charsley, blink-dev
/deep/ in the static css profile is discussed here:
We do not have a consensus yet.
Reply all
Reply to author
0 new messages