Intent to Implement: Shadow DOM - closed mode

[Hayato Ito]

Contact emails

hay...@chromium.org

Spec

Shadow DOM spec

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

The relevant W3C bug: [Shadow]: Add "closed" flag to createShadowRoot

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]

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

[1]: https://chromium.googlesource.com/chromium/blink/+/295a4d94fc/Source/core/dom/StyleElement.cpp#157

[2]: https://codereview.chromium.org/516273002/#msg11

[Chris Harrelson]

LGTM!

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

[Philip Rogers]

LGTM. This name is pretty fly too.

[Philip Jägenstedt]

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

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]

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]

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

[Philip Jägenstedt]

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]

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]

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]

Is shadow dom with closed mode support being worked on at the moment? Is it tracked somewhere?

[Takayoshi Kochi]

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:

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

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]

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:

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

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:

https://www.chromestatus.com/metrics/feature/timeline/popularity/456

Philip 

[Takayoshi Kochi]

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.

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

 

Philip 

--

Takayoshi Kochi

[Philip Jägenstedt]

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]

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]

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]

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]

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]

This issue,  https://github.com/w3c/webcomponents/issues/130, might be a good place to discuss.

[Ojan Vafai]

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]

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]

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]

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