Intent to Implement: Shadow DOM - closed mode

435 views
Skip to first unread message

Hayato Ito

unread,
Mar 2, 2015, 7:32:08 AM3/2/15
to blink-dev
Contact emails

Spec
W3C bug for tracking closed shadow trees: [Shadow]: Define the behavior of *closed* shadow trees

Summary
Allow developers to create a closed shadow tree, whose previous name is an User-Agent shadow tree.

Motivation
Blink has two kinds of shadow trees as follows:
1. Author shadow tree: A shadow tree which developers can create via element.createShadowRoot().
2. User-Agent shadow tree: A shadow tree which is internally used in blink to implement some of built-in elements, such as <video>, <details>/<summary>, <input> and so on.

In short, the difference between two shadow trees is:
- Developers can't access User-Agent shadow trees by any means. In contrast, developers can access Author shadow tree if they have an explicit intention to access.

I have an intent to implement and expose the API to developers so that they can create User-Agent shadow trees. One of the benefits is that developers can create a custom element which has completely (or nearly) equivalent behavior to built-in elements, if developers prefer such a behavior.

We've discussed pros and cons about "public vs private", "open vs closed" shadow trees many times in public-...@w3c.org.
You can see the links to discussions in github W3C / Web Components / Shadow DOM Contentious Bits.

The conclusion of Web Apps f2f Meeting is: We agreed to add the closed mode to the spec. See the meeting minutes (and search by "encapsulation").

To avoid confusion, an {Author/UserAgent} shadow tree was already renamed to an {Open/Closed} shadow tree here.

Compatibility Risk
No, as long as we won't change the default. The default is open as of now.

Ongoing technical constraints
No

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

OWP launch tracking bug
The relevant tracking bug in blink is: https://code.google.com/p/chromium/issues/detail?id=459136

Requesting approval to ship?
No.

Jeremy Roman

unread,
Mar 2, 2015, 11:51:06 AM3/2/15
to Hayato Ito, blink-dev
Have you audited the behaviours associated with UA shadow roots? For example, because their content was assumed to be UA-supplied, they were granted permission to load inline style without CSP approval [1][2]. That reasoning doesn't apply if we don't distinguish between user-agent ("trusted", in some sense) and closed author roots.
(We might just want to remove this particular behaviour, as the feature I intended to use it for is on ice and probably nothing else relies on it. But I'm not certain that there aren't other places where we have the "UA shadow roots are trusted" assumption.)

Chris Harrelson

unread,
Mar 2, 2015, 1:16:04 PM3/2/15
to Hayato Ito, blink-dev
LGTM!

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

Philip Rogers

unread,
Mar 2, 2015, 2:07:34 PM3/2/15
to Chris Harrelson, Hayato Ito, blink-dev
LGTM. This name is pretty fly too.

Philip Jägenstedt

unread,
Mar 2, 2015, 11:15:49 PM3/2/15
to Philip Rogers, Chris Harrelson, Hayato Ito, blink-dev
LGTM3, I've already made acquaintance with closed shadow trees in <video controls> and recently the bug that allowed /deep/ to reach inside was fixed. Given Web developers this power as well sounds great.

One thing to clarify regarding "Developers can't access User-Agent shadow trees by any means." Unfortunately, it's still possible to style them with CSS and do crazy things. Here's an example where the media controls are moved outside of the video entirely:

I will be very happy the day we block this (today?) because it's a pain to deal with interfering styles in the media controls code and there have even been crashes due to incorrect assumptions based on this.

Philip

Hayato Ito

unread,
Mar 2, 2015, 11:37:51 PM3/2/15
to Jeremy Roman, blink-dev
On Tue, Mar 3, 2015 at 1:50 AM Jeremy Roman <jbr...@chromium.org> wrote:
Have you audited the behaviours associated with UA shadow roots? For example, because their content was assumed to be UA-supplied, they were granted permission to load inline style without CSP approval [1][2]. That reasoning doesn't apply if we don't distinguish between user-agent ("trusted", in some sense) and closed author roots.
(We might just want to remove this particular behaviour, as the feature I intended to use it for is on ice and probably nothing else relies on it. But I'm not certain that there aren't other places where we have the "UA shadow roots are trusted" assumption.)


Not yet. We have to audit every current usages. I appreciate any feedbacks about how the current UA shadow roots are being used and what assumption we have there.

Since I don't want to add new kind of shadow trees any more, my current plan is that we have only two (open and closed), instead of three (open, UA closed and author closed), if it's possible.

Note that I'm not optimistic about that we don't have to distinguish UA closed and author closed at all. Maybe we have to distinguish these somehow (by another flag), however, I'd like to minimize the difference between them.

Hayato Ito

unread,
Mar 2, 2015, 11:42:23 PM3/2/15
to Philip Jägenstedt, Philip Rogers, Chris Harrelson, blink-dev
On Tue, Mar 3, 2015 at 1:15 PM Philip Jägenstedt <phi...@opera.com> wrote:
LGTM3, I've already made acquaintance with closed shadow trees in <video controls> and recently the bug that allowed /deep/ to reach inside was fixed. Given Web developers this power as well sounds great.

One thing to clarify regarding "Developers can't access User-Agent shadow trees by any means." Unfortunately, it's still possible to style them with CSS and do crazy things. Here's an example where the media controls are moved outside of the video entirely:


Yeah, that's exception due to the historical reasons. We have to live in a world with "::webkit-" pseudo elements for the time being (or forever?).

Philip Jägenstedt

unread,
Mar 3, 2015, 12:44:34 AM3/3/15
to Hayato Ito, Philip Rogers, Chris Harrelson, blink-dev
On Tue, Mar 3, 2015 at 11:42 AM, Hayato Ito <hay...@chromium.org> wrote:
>
>
>
> On Tue, Mar 3, 2015 at 1:15 PM Philip Jägenstedt <phi...@opera.com> wrote:
>>
>> LGTM3, I've already made acquaintance with closed shadow trees in <video controls> and recently the bug that allowed /deep/ to reach inside was fixed. Given Web developers this power as well sounds great.
>>
>> One thing to clarify regarding "Developers can't access User-Agent shadow trees by any means." Unfortunately, it's still possible to style them with CSS and do crazy things. Here's an example where the media controls are moved outside of the video entirely:
>> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3435
>>
>
> Yeah, that's exception due to the historical reasons. We have to live in a world with "::webkit-" pseudo elements for the time being (or forever?).

Some may be forever, but I sent an Intent to Deprecate and Remove: ::-webkit-media-controls* pseudo-element selectors last October when dealing with the aforementioned crash. In the end another solution was used, but I think it's pretty likely that making these pseudo elements internal would be Web compatible. But that's kind of off-topic :)

Philip

Anne van Kesteren

unread,
Mar 3, 2015, 2:34:02 AM3/3/15
to Philip Jägenstedt, Hayato Ito, Philip Rogers, Chris Harrelson, blink-dev
On Tue, Mar 3, 2015 at 6:44 AM, Philip Jägenstedt <phi...@opera.com> wrote:
> Some may be forever, but I sent an Intent to Deprecate and Remove:
> ::-webkit-media-controls* pseudo-element selectors last October when dealing
> with the aforementioned crash. In the end another solution was used, but I
> think it's pretty likely that making these pseudo elements internal would be
> Web compatible. But that's kind of off-topic :)

We should find a way however to allow (limited) styling from the
outside even when the control is isolated. Perhaps through CSS
variables or whitelisting properties, but not allowing any styling
ensures that native controls get rewritten in JavaScript (likely less
accessible).


--
https://annevankesteren.nl/

Philip Jägenstedt

unread,
Mar 3, 2015, 12:53:00 PM3/3/15
to Anne van Kesteren, Hayato Ito, Philip Rogers, Chris Harrelson, blink-dev
For <video controls>, we've been saying that it would be nice to be
able to style them since the beginning, but I don't think it'll
actually happen. Some limited styling wouldn't be expressive enough to
get the desired results, and any powerful styling would be hard to
make interoperable. But I should reserve judgement until there's an
actual proposal I guess.

Philip

tho...@tjconcept.dk

unread,
Sep 5, 2015, 2:32:00 PM9/5/15
to blink-dev
Is shadow dom with closed mode support being worked on at the moment? Is it tracked somewhere?

Takayoshi Kochi

unread,
Sep 6, 2015, 9:58:46 AM9/6/15
to tho...@tjconcept.dk, blink-dev
On Sun, Sep 6, 2015 at 3:31 AM, <tho...@tjconcept.dk> wrote:
Is shadow dom with closed mode support being worked on at the moment? Is it tracked somewhere?


It's tracked at:

The functionality is implemented, but with using old interface (createShadowRoot({mode: 'closed'})).
In the latest shadow dom spec, now it is renamed to attachShadow() to avoid conflict with
old createShadowRoot().  The rename part is not yet implemented at this moment.



--
Takayoshi Kochi

Philip Jägenstedt

unread,
Sep 8, 2015, 4:25:30 AM9/8/15
to Takayoshi Kochi, tho...@tjconcept.dk, blink-dev
On Sun, Sep 6, 2015 at 3:57 PM, Takayoshi Kochi <ko...@chromium.org> wrote:


On Sun, Sep 6, 2015 at 3:31 AM, <tho...@tjconcept.dk> wrote:
Is shadow dom with closed mode support being worked on at the moment? Is it tracked somewhere?


It's tracked at:

The functionality is implemented, but with using old interface (createShadowRoot({mode: 'closed'})).
In the latest shadow dom spec, now it is renamed to attachShadow() to avoid conflict with
old createShadowRoot().  The rename part is not yet implemented at this moment.

It looks like createShadowRoot() is gone from the spec entirely, is that intentional? Given the usage it doesn't seem possible to remove, and unless we intent to remove it there ought to be some spec describing it:

Philip 

Takayoshi Kochi

unread,
Sep 8, 2015, 4:37:07 AM9/8/15
to Philip Jägenstedt, Thomas Jensen, blink-dev
Yes, createShadowRoot() is already used much and hard to deprecate,
so the spec intends to allow parameters only with a newly named API attachShadow().
createShadowRoot() will be kept for the time being, but will reject parameter once
attachShadow() is added.

createShadowRoot() with mode parameter is still under experimental flag and
probably our LayoutTest is probably the only user,
migrating to attachShadow() shouldn't cause any confusion.

See also detail in Hayato's memo on the migration plan.

 
Philip 


--
Takayoshi Kochi

Philip Jägenstedt

unread,
Sep 8, 2015, 4:45:28 AM9/8/15
to Takayoshi Kochi, Thomas Jensen, blink-dev
Thanks, it looks like the answer to my question is under "It looks that Element.createShadowRoot() and <content>were removed from the spec. Does Blink continue to supportcreateShadowRoot and <content>?"

However, the answer is that it will continue to be supported without a spec, which I don't understand. If it's used so much that Blink cannot remove it, it seems almost inevitable that other browsers will be forced to implement it, so why is it not simply included in the Shadow DOM spec?

Philip

Takayoshi Kochi

unread,
Sep 8, 2015, 4:54:07 AM9/8/15
to Philip Jägenstedt, Thomas Jensen, blink-dev
I don't believe other browsers will be *forced* to implement createShadowRoot/<content>,
as there will be more interoperable alternative attachShadow/<slot> in the spec.

 
Philip



--
Takayoshi Kochi

Philip Jägenstedt

unread,
Sep 8, 2015, 5:28:46 AM9/8/15
to Takayoshi Kochi, Thomas Jensen, blink-dev
Unless usage of createShadowRoot() or Chrome's market share falls to insignificant levels, this case seems pretty likely to end up like WebKitCSSMatrix, @media(-webkit-transform-3d) and other APIs that are now being specified in https://compat.spec.whatwg.org/

If we mean to support createShadowRoot() indefinitely, can it not be described in the Shadow DOM spec?

Philip

Hayato Ito

unread,
Sep 8, 2015, 11:43:13 PM9/8/15
to Philip Jägenstedt, Takayoshi Kochi, Thomas Jensen, blink-dev
Please see the following section for a tentative plan to support createShadowRoot and <content> in Blink, which I updated in the last week.

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/shadow-dom-v1-in-blink.md#unified-distribution

Hayato Ito

unread,
Sep 9, 2015, 12:02:05 AM9/9/15
to Philip Jägenstedt, Takayoshi Kochi, Thomas Jensen, blink-dev
Ops. The URL was already mentioned in this discussion. :)

If you think the spec should mention createShadowRoot and <content>, could you file an issue to the spec, https://github.com/w3c/webcomponents/issues ?
Maybe we should explain the historical reason why the spec has them and should mention it's up to UAs to implement.

Hayato Ito

unread,
Sep 9, 2015, 12:08:05 AM9/9/15
to Philip Jägenstedt, Takayoshi Kochi, Thomas Jensen, blink-dev
This issue,  https://github.com/w3c/webcomponents/issues/130, might be a good place to discuss.

Ojan Vafai

unread,
Sep 9, 2015, 1:27:40 AM9/9/15
to Philip Jägenstedt, Takayoshi Kochi, Thomas Jensen, blink-dev
If Chrome is the only browser to ever ship this API, there's little threat of the webkit prefix issue happening here. This API isn't shipping in Safari, so, unlike webkit prefixes all the code already has to have a fallback to be usable for the majority of users and since Chrome auto-updates so frequently, I expect many pages will migrate over as soon as Safari is close to shipping this (or sooner).

If we mean to support createShadowRoot() indefinitely, can it not be described in the Shadow DOM spec? 

We can wait until other browser vendors have shipped to evaluate the landscape and see if removing is feasible. I expect it will be. If it's not, we can always spec it at that point.
 

Philip

Philip Jägenstedt

unread,
Sep 9, 2015, 5:16:29 AM9/9/15
to Ojan Vafai, Takayoshi Kochi, Thomas Jensen, blink-dev
Yes, the risk is lower than when WebKit alone accounted a large majority of the mobile web, but Chrome alone is still big enough that Chrome-specific code paths are plausible, and other browsers could start getting those if they follow Edge in identifying as Chrome in the UA string.

If we mean to support createShadowRoot() indefinitely, can it not be described in the Shadow DOM spec? 

We can wait until other browser vendors have shipped to evaluate the landscape and see if removing is feasible. I expect it will be. If it's not, we can always spec it at that point.

An explicit plan to deprecate would be great, IMHO. To ship the new attachShadow() API or to encourage other vendors to do so without some level of confidence in the ability to remove the old API risks being too optimistic about the ability to change things once shipped, and in the ability to influence usage of an API in the wild.

Philip

Anne van Kesteren

unread,
Sep 9, 2015, 5:22:00 AM9/9/15
to Philip Jägenstedt, Ojan Vafai, Takayoshi Kochi, Thomas Jensen, blink-dev
Note that it's not just the entry point that is different, shadow DOM
itself is a bit different as well (e.g., <content> -> <slot>). So
unless developers branch, their code will not work in browsers that
only implement the new model.


--
https://annevankesteren.nl/

Philip Jägenstedt

unread,
Sep 9, 2015, 5:27:51 AM9/9/15
to Anne van Kesteren, Ojan Vafai, Takayoshi Kochi, Thomas Jensen, blink-dev
Yeah, I assumed as much, but I'm not sure if this increases or
decreases the overall risk. The worst case scenario would be that both
models end up having to co-exist and that their interaction is
underspecified and/or full of tricky corner cases. That is of course
what https://github.com/w3c/webcomponents/issues/130 is about.

Philip
Reply all
Reply to author
Forward
0 new messages