Shadow DOM v1: Status updates

367 views
Skip to first unread message

Hayato Ito

unread,
Feb 29, 2016, 1:13:42 AM2/29/16
to blink-dev
Since I have been receiving several inquiries about the status of Shadow DOM v1 in Blink, let me report the progress of Shadow DOM v1 in Blink (and the spec) here.

TL;DR.
  • There are still a lot of active discussions happening on the Shadow DOM spec.
  • I do not ship Shadow DOM v1 until all v1 issues [1] of the spec are resolved and we can make sure that Blink has a spec-compliant implementation.
  • The original plan to send "Intent to ship: Shadow DOM v1" is in the next quarter, however, I expect that it might be delayed, given that we still have feature requests for v1.
  • You can experiment Shadow DOM v1 in Blink by enabling "experimental Web Platform features" flag in chrome://flags/. Your feedback is highly appreciated.
  • I guarantee that Shadow DOM v0 will continue to work after Shadow DOM v1 is shipped. There is no ETA to deprecate Shadow DOM v0, as of now.

Here is the summary of the (planned) incoming changes and their status in Blink:

New Web-facing APIs are:
  • Element:
    • Element.attachShadow(ShadowRootInitDict) [Done]
    • Element.assignedSlot [Done]
    • Element.slot [Done]
  • New HTML Element, called <slot> [Done]
    • Slot.assignedNode(dict) [Done]
  • Text:
    • Text.assignedSlot - [Done]
  • Event:
    • Event.scoped - [Done]
    • Event.relatedTargetScoped: - [WIP]
    • Event.deepPath() - [Done]
    • New Event.deepPath() behavior [Issue #373] [Done]
  • New Event (or New MutationRecord)
  • Node:
  • New CSS pseudo elements
    • "::slotted" [Issue #331] [Mostly Done in Blink. The spec needs to be updated] 

In addition to the new APIs, Blink will have the following new behaviors for shadow trees, which are enabled only if the new API, attachShadow, is used.

New behavior of shadow trees:
  • Support a closed mode, in addition to an open mode [Done]
  • Slots based distributions, including the support of fallback contents (See this CL for details) [Mostly Done]
  • New CSS Cascading Order [issue #316] [WIP]
  • ShadowRoot.delegatesFocus [Issue #126] [WIP, the spec needs to be updated] 
  • New ShadowRoot.activeElement behavior [issue #358]  [WIP, the spec needs to be updated] 
  • New focus navigation behavior which is aware of slots [issue #375] [WIP, the spec needs to be updated]
 I have a plan to write a user-friendly document for each feature later.

What makes us busy:
  • Resolve all spec issues
  • Investigate a feasibility, write a spec, and implement an incoming feature request, such as:
    • New focus navigation behaviors
    • "slotchange" event. I might need to rewrite the distribution code to support this feature efficiently. Needs to investigate further.

Shadow DOM v1 is getting much changes and features, compared to when I sent "Intent to implement: Shadow DOM v1" mail [2]. We might need to send multiple "Intent to Ship" mails, if it would be a safer way to ship each feature, incrementally. I'll report the status again at the end of this quarter.

References:


Philip Jägenstedt

unread,
Feb 29, 2016, 3:51:42 AM2/29/16
to Hayato Ito, blink-dev
Does v1 match the specific subset that would allow you to deprecate v0, or is it everything currently in the spec? If Shadow DOM is anything like DOM and HTML, it will be perpetually in-progress, and that's fine, but it would be sad if removing v0 is blocked on shipping new, unrelated functionality.

I don't know if it's the case here, but setting a high quality bar for shipping v1 could delay the deprecation of v0 and increase the probability that it will stay around forever.

--
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+...@chromium.org.

Hayato Ito

unread,
Feb 29, 2016, 4:35:33 AM2/29/16
to Philip Jägenstedt, blink-dev
On Mon, Feb 29, 2016 at 5:51 PM Philip Jägenstedt <phi...@opera.com> wrote:
Does v1 match the specific subset that would allow you to deprecate v0, or is it everything currently in the spec? If Shadow DOM is anything like DOM and HTML, it will be perpetually in-progress, and that's fine, but it would be sad if removing v0 is blocked on shipping new, unrelated functionality.


v1 is not the subset of the current spec. v1 is everything currently in the spec. I've rewritten most of the specs for v1.
Actually, to make the difference between v0 and v1 clear, we have introduced a lot of new APIs, such as Element.attachShadow().
It's not the goal of v1 to maintain the compatibility with v0. The goal of v1 is to define the feature sets on which all browser vendors agree to implement.

You can think that v0 and v1 solve the same problem with different API sets. In this sense, v0 and v1 are related.

Philip Jägenstedt

unread,
Feb 29, 2016, 5:13:15 AM2/29/16
to Hayato Ito, blink-dev
On Mon, Feb 29, 2016 at 4:35 PM, Hayato Ito <hay...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 5:51 PM Philip Jägenstedt <phi...@opera.com> wrote:
Does v1 match the specific subset that would allow you to deprecate v0, or is it everything currently in the spec? If Shadow DOM is anything like DOM and HTML, it will be perpetually in-progress, and that's fine, but it would be sad if removing v0 is blocked on shipping new, unrelated functionality.


v1 is not the subset of the current spec. v1 is everything currently in the spec. I've rewritten most of the specs for v1.
Actually, to make the difference between v0 and v1 clear, we have introduced a lot of new APIs, such as Element.attachShadow().
It's not the goal of v1 to maintain the compatibility with v0. The goal of v1 is to define the feature sets on which all browser vendors agree to implement.

You can think that v0 and v1 solve the same problem with different API sets. In this sense, v0 and v1 are related.

Thanks, this is pretty much as I suspected. You mentioned that there is no ETA to deprecate v0, but is there a rough plan, and idea of how it's going to play out?

The situation looks quite worrisome to me. With high usage of v0's createShadowRoot it would take something extraordinary to not end up with both APIs side-by-side indefinitely. This was discussion in a previous thread where I was equally pessimistic, but I haven't really followed along since then.

Philip

Hayato Ito

unread,
Feb 29, 2016, 5:50:03 AM2/29/16
to Philip Jägenstedt, blink-dev
On Mon, Feb 29, 2016 at 7:13 PM Philip Jägenstedt <phi...@opera.com> wrote:
On Mon, Feb 29, 2016 at 4:35 PM, Hayato Ito <hay...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 5:51 PM Philip Jägenstedt <phi...@opera.com> wrote:
Does v1 match the specific subset that would allow you to deprecate v0, or is it everything currently in the spec? If Shadow DOM is anything like DOM and HTML, it will be perpetually in-progress, and that's fine, but it would be sad if removing v0 is blocked on shipping new, unrelated functionality.


v1 is not the subset of the current spec. v1 is everything currently in the spec. I've rewritten most of the specs for v1.
Actually, to make the difference between v0 and v1 clear, we have introduced a lot of new APIs, such as Element.attachShadow().
It's not the goal of v1 to maintain the compatibility with v0. The goal of v1 is to define the feature sets on which all browser vendors agree to implement.

You can think that v0 and v1 solve the same problem with different API sets. In this sense, v0 and v1 are related.

Thanks, this is pretty much as I suspected. You mentioned that there is no ETA to deprecate v0, but is there a rough plan, and idea of how it's going to play out?


Yeah, the rough plan I had a couple of months ago is here:
 
Originally, I planned to start to deprecate v0 in 2016 Q4. However, please do not consider it as a commitment. I have to update the original plan, considering the current situation.
If we can see the smooth migration from v0 to v1, we might want to deprecate v0 more aggressively.

It would be difficult to predict how the migration go smoothy unless we can ship v1 and see what's going on in the real world.

Philip Jägenstedt

unread,
Feb 29, 2016, 6:33:20 AM2/29/16
to Hayato Ito, blink-dev
On Mon, Feb 29, 2016 at 5:49 PM, Hayato Ito <hay...@chromium.org> wrote:


On Mon, Feb 29, 2016 at 7:13 PM Philip Jägenstedt <phi...@opera.com> wrote:
On Mon, Feb 29, 2016 at 4:35 PM, Hayato Ito <hay...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 5:51 PM Philip Jägenstedt <phi...@opera.com> wrote:
Does v1 match the specific subset that would allow you to deprecate v0, or is it everything currently in the spec? If Shadow DOM is anything like DOM and HTML, it will be perpetually in-progress, and that's fine, but it would be sad if removing v0 is blocked on shipping new, unrelated functionality.


v1 is not the subset of the current spec. v1 is everything currently in the spec. I've rewritten most of the specs for v1.
Actually, to make the difference between v0 and v1 clear, we have introduced a lot of new APIs, such as Element.attachShadow().
It's not the goal of v1 to maintain the compatibility with v0. The goal of v1 is to define the feature sets on which all browser vendors agree to implement.

You can think that v0 and v1 solve the same problem with different API sets. In this sense, v0 and v1 are related.

Thanks, this is pretty much as I suspected. You mentioned that there is no ETA to deprecate v0, but is there a rough plan, and idea of how it's going to play out?


Yeah, the rough plan I had a couple of months ago is here:
 
Originally, I planned to start to deprecate v0 in 2016 Q4. However, please do not consider it as a commitment. I have to update the original plan, considering the current situation.
If we can see the smooth migration from v0 to v1, we might want to deprecate v0 more aggressively.

It would be difficult to predict how the migration go smoothy unless we can ship v1 and see what's going on in the real world.

I think I have seen that doc before, thanks for reminding me.

Among the listed changes, my main concern is with createShadowRoot/attachRoot and path/deepPath. At least from a distance, this renaming doesn't look strictly necessary. Whatever benefit there is in renaming, it has to outweigh the pretty significant risk that we'll simply have both forms forever. path and deepPath would presumably be aliases, but the implementations of createShadowRoot and attachRoot are not exactly the same.

From the rename createShadowRoot to attachShadow issue I can't quite glean what the problem was, why is it that createShadowRoot could not be given the extra (optional) argument and otherwise match the new attachShadow?

Also, it looks like there aren't any use counters for <content> and <shadow>?

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.

Philip

Hayato Ito

unread,
Mar 1, 2016, 1:50:47 AM3/1/16
to Philip Jägenstedt, blink-dev
Regarding path/deepPath, renaming `path` to `deepPath` is the resolution at Shadow DOM f2f meeting last year. Then, deepPath has diverged:
  - deepPath() became a method, while `path` remains to be a property for the backward compatibility.
  - deepPath() has adapted a new behavior: It returns an empty array if an event is no longer dispatched. See https://github.com/w3c/webcomponents/issues/373 for the rational.
Thus, they are no longer aliases to each other.

Regarding createShadowRoot()/attachShadow(), I do not have any strong opinion on this *renaming*. As you said, we could choose to make createShadowRoot() take the extra argument, however, some of us thought that it might be simply confusing, and it would be better to have another name for v1 because v0 and v1 would have different semantics, AFAIR.
 
Also, it looks like there aren't any use counters for <content> and <shadow>?

I never thought to have a use counter for <content>, however, I do not think we get much benefits by having a use counter for <content> for the purpose of deprecation because:
- It never happens to deprecate only <content>, without deprecating createShadowRoot(). That's unlikely.
- If we deprecate createShadowRoot(), that means we deprecate <content> too because <content> can not live without a createShadowRoot().

Regarding <shadow>, <shadow> should be always used together with multiple shadow roots feature, which has a use counter:
 

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.


I totally agree on your concerns. Blink had to pay much cost to spread Shadow DOM into all browser vendors. If you have any idea to minimize our burden, let share it with us.
 
Philip

Philip Jägenstedt

unread,
Mar 1, 2016, 12:09:19 PM3/1/16
to Hayato Ito, blink-dev
On Tue, Mar 1, 2016 at 1:50 PM, Hayato Ito <hay...@chromium.org> wrote:


On Mon, Feb 29, 2016 at 8:33 PM Philip Jägenstedt <phi...@opera.com> wrote:
On Mon, Feb 29, 2016 at 5:49 PM, Hayato Ito <hay...@chromium.org> wrote:


On Mon, Feb 29, 2016 at 7:13 PM Philip Jägenstedt <phi...@opera.com> wrote:
On Mon, Feb 29, 2016 at 4:35 PM, Hayato Ito <hay...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 5:51 PM Philip Jägenstedt <phi...@opera.com> wrote:
Does v1 match the specific subset that would allow you to deprecate v0, or is it everything currently in the spec? If Shadow DOM is anything like DOM and HTML, it will be perpetually in-progress, and that's fine, but it would be sad if removing v0 is blocked on shipping new, unrelated functionality.


v1 is not the subset of the current spec. v1 is everything currently in the spec. I've rewritten most of the specs for v1.
Actually, to make the difference between v0 and v1 clear, we have introduced a lot of new APIs, such as Element.attachShadow().
It's not the goal of v1 to maintain the compatibility with v0. The goal of v1 is to define the feature sets on which all browser vendors agree to implement.

You can think that v0 and v1 solve the same problem with different API sets. In this sense, v0 and v1 are related.

Thanks, this is pretty much as I suspected. You mentioned that there is no ETA to deprecate v0, but is there a rough plan, and idea of how it's going to play out?


Yeah, the rough plan I had a couple of months ago is here:
 
Originally, I planned to start to deprecate v0 in 2016 Q4. However, please do not consider it as a commitment. I have to update the original plan, considering the current situation.
If we can see the smooth migration from v0 to v1, we might want to deprecate v0 more aggressively.

It would be difficult to predict how the migration go smoothy unless we can ship v1 and see what's going on in the real world.

I think I have seen that doc before, thanks for reminding me.

Among the listed changes, my main concern is with createShadowRoot/attachRoot and path/deepPath. At least from a distance, this renaming doesn't look strictly necessary. Whatever benefit there is in renaming, it has to outweigh the pretty significant risk that we'll simply have both forms forever. path and deepPath would presumably be aliases, but the implementations of createShadowRoot and attachRoot are not exactly the same.

From the rename createShadowRoot to attachShadow issue I can't quite glean what the problem was, why is it that createShadowRoot could not be given the extra (optional) argument and otherwise match the new attachShadow?


Regarding path/deepPath, renaming `path` to `deepPath` is the resolution at Shadow DOM f2f meeting last year. Then, deepPath has diverged:
  - deepPath() became a method, while `path` remains to be a property for the backward compatibility.
  - deepPath() has adapted a new behavior: It returns an empty array if an event is no longer dispatched. See https://github.com/w3c/webcomponents/issues/373 for the rational.
Thus, they are no longer aliases to each other.

That's interesting. From the issue I can't decipher why it's been made into a method, why was that? It seems like if path needs to remain as an attribute and is just a filtered view of deepPath, then there can be no fundamental reason for one to be an attribute and the other a method. WebIDL now has FrozenArray<T>, if "don't return a new object every time" was part of the original concern leading to a method.

Is the hope still for Event#path to be added to DOM itself?

Regarding createShadowRoot()/attachShadow(), I do not have any strong opinion on this *renaming*. As you said, we could choose to make createShadowRoot() take the extra argument, however, some of us thought that it might be simply confusing, and it would be better to have another name for v1 because v0 and v1 would have different semantics, AFAIR.

Did this difference in semantics become as big as anticipated? There are quite many places that check for ShadowRootType::V0, are all of those related to the already-deprecated behaviors of multiple shadow roots? In other words, if those bits are removed, is it within reach to fold V0 into the open mode?

Also, it looks like there aren't any use counters for <content> and <shadow>?

I never thought to have a use counter for <content>, however, I do not think we get much benefits by having a use counter for <content> for the purpose of deprecation because:
- It never happens to deprecate only <content>, without deprecating createShadowRoot(). That's unlikely.
- If we deprecate createShadowRoot(), that means we deprecate <content> too because <content> can not live without a createShadowRoot().

Regarding <shadow>, <shadow> should be always used together with multiple shadow roots feature, which has a use counter:

OK, I didn't know anything about these elements except how to spell them. Even if neither <content> nor <shadow> make any sense in the absence of createShadowRoot, it could still turn out that their usage is far smaller than that of createShadowRoot, and that they can be removed first. But if that doesn't strike you as a sane path to take, then of course there's no reason to add use counters just for the fun of it :)

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.


I totally agree on your concerns. Blink had to pay much cost to spread Shadow DOM into all browser vendors. If you have any idea to minimize our burden, let share it with us.

Perhaps promises have already been made to other browser vendors that make these ideas intractable, but if I could wave an interop- and compat-issue-minimizing wand, it would probably go something like this:
  • Assuming that multiple shadow roots is the main source of uncertainty, determine what is blocking removal of multiple shadow roots and accelerate its removal. If there's just no way to investigate, maybe remove them on dev and beta for a few weeks just to find out what the top breakage is. Then set a reasonable date for removal and do it.
  • Change attachShadow back to createShadowRoot with an optional ShadowRootInit argument, where open is the default mode. Deprecate and remove any remaining differences between ShadowRootType::V0 and ShadowRootType::Open where usage is low, and standardize the rest.
  • Change Event#path to FrozenArray<EventTarget> and standardize as-is, abandoning hope of renaming it to deepPath. (This assumes that the the local path is easily determined from the full path, and it looks like it is because the ShadowRoot is included.)
I'm not incredibly familiar with Shadow DOM so perhaps all of this is nonsense, but it seems like a gamble to hope that significant changes to what has been shipping for a very long time will work out. createShadowRoot and the current Event#path don't seem to be anywhere near broken enough to justify that risk.

Happy to learn more about this, and how others think this tricky situation should be handled.

Philip

Hayato Ito

unread,
Mar 1, 2016, 9:17:00 PM3/1/16
to Philip Jägenstedt, blink-dev
You can see the discussion here: https://github.com/w3c/webcomponents/issues/361. I appreciate if you could comment there, where you can get an opinion also from other browser vendors and standard folks. Because I made a final decision to make it a method, I would be confident with my decision. :)
 
Is the hope still for Event#path to be added to DOM itself?

It is unlikely, given that Event.path was already removed from the spec.
 

Regarding createShadowRoot()/attachShadow(), I do not have any strong opinion on this *renaming*. As you said, we could choose to make createShadowRoot() take the extra argument, however, some of us thought that it might be simply confusing, and it would be better to have another name for v1 because v0 and v1 would have different semantics, AFAIR.

Did this difference in semantics become as big as anticipated? There are quite many places that check for ShadowRootType::V0, are all of those related to the already-deprecated behaviors of multiple shadow roots? In other words, if those bits are removed, is it within reach to fold V0 into the open mode?

No. They have different semantics. The following ShadowRootType's flags,

- V0
- Open
- Close

, are actually

- V0 and Open
- V1 and Open
- V1 and Close

, roughly.


 

Also, it looks like there aren't any use counters for <content> and <shadow>?

I never thought to have a use counter for <content>, however, I do not think we get much benefits by having a use counter for <content> for the purpose of deprecation because:
- It never happens to deprecate only <content>, without deprecating createShadowRoot(). That's unlikely.
- If we deprecate createShadowRoot(), that means we deprecate <content> too because <content> can not live without a createShadowRoot().

Regarding <shadow>, <shadow> should be always used together with multiple shadow roots feature, which has a use counter:

OK, I didn't know anything about these elements except how to spell them. Even if neither <content> nor <shadow> make any sense in the absence of createShadowRoot, it could still turn out that their usage is far smaller than that of createShadowRoot, and that they can be removed first. But if that doesn't strike you as a sane path to take, then of course there's no reason to add use counters just for the fun of it :)

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.


I totally agree on your concerns. Blink had to pay much cost to spread Shadow DOM into all browser vendors. If you have any idea to minimize our burden, let share it with us.

Perhaps promises have already been made to other browser vendors that make these ideas intractable, but if I could wave an interop- and compat-issue-minimizing wand, it would probably go something like this:
  • Assuming that multiple shadow roots is the main source of uncertainty, determine what is blocking removal of multiple shadow roots and accelerate its removal. If there's just no way to investigate, maybe remove them on dev and beta for a few weeks just to find out what the top breakage is. Then set a reasonable date for removal and do it.

As far as I know, the main source of multiple shadow roots is still the old version of Polymer, if the situation does not change.
 
  • Change attachShadow back to createShadowRoot with an optional ShadowRootInit argument, where open is the default mode. Deprecate and remove any remaining differences between ShadowRootType::V0 and ShadowRootType::Open where usage is low, and standardize the rest.
  • Change Event#path to FrozenArray<EventTarget> and standardize as-is, abandoning hope of renaming it to deepPath. (This assumes that the the local path is easily determined from the full path, and it looks like it is because the ShadowRoot is included.)
I'm not incredibly familiar with Shadow DOM so perhaps all of this is nonsense, but it seems like a gamble to hope that significant changes to what has been shipping for a very long time will work out. createShadowRoot and the current Event#path don't seem to be anywhere near broken enough to justify that risk.

Happy to learn more about this, and how others think this tricky situation should be handled.

Yeah, I am happy to answer your concerns. I appreciate if you could help me to handle this tricky situation.
 

Philip

Hayato Ito

unread,
Mar 1, 2016, 11:31:38 PM3/1/16
to Philip Jägenstedt, blink-dev
Ops. Correction:
s/I would be confident with my decision./I would like to be confident in my decision./

jarek...@gmail.com

unread,
Mar 2, 2016, 1:08:23 AM3/2/16
to blink-dev, phi...@opera.com
I was hoping you would not remove support for Shadow DOM v0 until v2 or v3 reaches the same level of functionality.

I'm making extensive use of SVG elements with shadow roots and if v0 is removed from Blink before shipping v2 or v3 with proper support for SVG then I will be in serious troubles. There would be no upgrade path other than reimplementing all SVG components to not use the Shadow DOM at all.

Philip Jägenstedt

unread,
Mar 9, 2016, 7:09:59 AM3/9/16
to Hayato Ito, blink-dev
I have commented on https://github.com/w3c/webcomponents/issues/361 with the suggestion of going back to just a FrozenArray<EventTarget> path attribute.

Failing that, would there be any way to eventually remove it? The use counter is hopelessly tainted by enumeration, so the only remaining tool would be httparchive data, but a short name like path is very grep-unfriendly. It would take serious dedication to get anywhere with a Event.path deprecation/removal, or is there a way?

Regarding createShadowRoot()/attachShadow(), I do not have any strong opinion on this *renaming*. As you said, we could choose to make createShadowRoot() take the extra argument, however, some of us thought that it might be simply confusing, and it would be better to have another name for v1 because v0 and v1 would have different semantics, AFAIR.

Did this difference in semantics become as big as anticipated? There are quite many places that check for ShadowRootType::V0, are all of those related to the already-deprecated behaviors of multiple shadow roots? In other words, if those bits are removed, is it within reach to fold V0 into the open mode?

No. They have different semantics. The following ShadowRootType's flags,

- V0
- Open
- Close

, are actually

- V0 and Open
- V1 and Open
- V1 and Close

, roughly.

To rephrase the question, if multiple shadow roots were removed, what would be the remaining differences between "V0 and Open" and "V1 and Open". If they are small then it looks hopeful that you could arrive at a single open mode, possibly by specifying some of the remaining quirks of "V0 and Open" for "V1 and Open" as well.

Conversely, if the differences are big, the obvious risk is that we'll just be stuck with three modes indefinitely.

Also, it looks like there aren't any use counters for <content> and <shadow>?

I never thought to have a use counter for <content>, however, I do not think we get much benefits by having a use counter for <content> for the purpose of deprecation because:
- It never happens to deprecate only <content>, without deprecating createShadowRoot(). That's unlikely.
- If we deprecate createShadowRoot(), that means we deprecate <content> too because <content> can not live without a createShadowRoot().

Regarding <shadow>, <shadow> should be always used together with multiple shadow roots feature, which has a use counter:

OK, I didn't know anything about these elements except how to spell them. Even if neither <content> nor <shadow> make any sense in the absence of createShadowRoot, it could still turn out that their usage is far smaller than that of createShadowRoot, and that they can be removed first. But if that doesn't strike you as a sane path to take, then of course there's no reason to add use counters just for the fun of it :)

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.


I totally agree on your concerns. Blink had to pay much cost to spread Shadow DOM into all browser vendors. If you have any idea to minimize our burden, let share it with us.

Perhaps promises have already been made to other browser vendors that make these ideas intractable, but if I could wave an interop- and compat-issue-minimizing wand, it would probably go something like this:
  • Assuming that multiple shadow roots is the main source of uncertainty, determine what is blocking removal of multiple shadow roots and accelerate its removal. If there's just no way to investigate, maybe remove them on dev and beta for a few weeks just to find out what the top breakage is. Then set a reasonable date for removal and do it.

As far as I know, the main source of multiple shadow roots is still the old version of Polymer, if the situation does not change.

If old versions of Polymer vanished today, would it be possible to go ahead with deprecation/removal of multiple shadow roots right now, or would it also be blocked on shipping v1?

  • Change attachShadow back to createShadowRoot with an optional ShadowRootInit argument, where open is the default mode. Deprecate and remove any remaining differences between ShadowRootType::V0 and ShadowRootType::Open where usage is low, and standardize the rest.
  • Change Event#path to FrozenArray<EventTarget> and standardize as-is, abandoning hope of renaming it to deepPath. (This assumes that the the local path is easily determined from the full path, and it looks like it is because the ShadowRoot is included.)
I'm not incredibly familiar with Shadow DOM so perhaps all of this is nonsense, but it seems like a gamble to hope that significant changes to what has been shipping for a very long time will work out. createShadowRoot and the current Event#path don't seem to be anywhere near broken enough to justify that risk.

Happy to learn more about this, and how others think this tricky situation should be handled.

Yeah, I am happy to answer your concerns. I appreciate if you could help me to handle this tricky situation.

Would you like me to file an issue to change attachShadow back to createShadowRoot, or do you personally prefer having them split even if it means keeping both forever? I think this comes down to how hard it is to merge "V0 and Open" into "V1 and Open".

Philip

Hayato Ito

unread,
Mar 9, 2016, 11:53:06 PM3/9/16
to Philip Jägenstedt, blink-dev
Thanks. We can continue the discussion in https://github.com/w3c/webcomponents/issues/428
 
Failing that, would there be any way to eventually remove it? The use counter is hopelessly tainted by enumeration, so the only remaining tool would be httparchive data, but a short name like path is very grep-unfriendly. It would take serious dedication to get anywhere with a Event.path deprecation/removal, or is there a way?

I have no idea. If someone have a nice idea, please let us know that.
 

Regarding createShadowRoot()/attachShadow(), I do not have any strong opinion on this *renaming*. As you said, we could choose to make createShadowRoot() take the extra argument, however, some of us thought that it might be simply confusing, and it would be better to have another name for v1 because v0 and v1 would have different semantics, AFAIR.

Did this difference in semantics become as big as anticipated? There are quite many places that check for ShadowRootType::V0, are all of those related to the already-deprecated behaviors of multiple shadow roots? In other words, if those bits are removed, is it within reach to fold V0 into the open mode?

No. They have different semantics. The following ShadowRootType's flags,

- V0
- Open
- Close

, are actually

- V0 and Open
- V1 and Open
- V1 and Close

, roughly.

To rephrase the question, if multiple shadow roots were removed, what would be the remaining differences between "V0 and Open" and "V1 and Open". If they are small then it looks hopeful that you could arrive at a single open mode, possibly by specifying some of the remaining quirks of "V0 and Open" for "V1 and Open" as well.


*New behavior of shadow trees* in the first post in this thread explains the differences between v0 and v1. That are the big differences.

Multiple shadow roots are just one of the differences. I guess I have omitted mentioning it in the first post because it was already deprecated and is irrelevant in shipping v1. 

Conversely, if the differences are big, the obvious risk is that we'll just be stuck with three modes indefinitely.

Also, it looks like there aren't any use counters for <content> and <shadow>?

I never thought to have a use counter for <content>, however, I do not think we get much benefits by having a use counter for <content> for the purpose of deprecation because:
- It never happens to deprecate only <content>, without deprecating createShadowRoot(). That's unlikely.
- If we deprecate createShadowRoot(), that means we deprecate <content> too because <content> can not live without a createShadowRoot().

Regarding <shadow>, <shadow> should be always used together with multiple shadow roots feature, which has a use counter:

OK, I didn't know anything about these elements except how to spell them. Even if neither <content> nor <shadow> make any sense in the absence of createShadowRoot, it could still turn out that their usage is far smaller than that of createShadowRoot, and that they can be removed first. But if that doesn't strike you as a sane path to take, then of course there's no reason to add use counters just for the fun of it :)

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.


I totally agree on your concerns. Blink had to pay much cost to spread Shadow DOM into all browser vendors. If you have any idea to minimize our burden, let share it with us.

Perhaps promises have already been made to other browser vendors that make these ideas intractable, but if I could wave an interop- and compat-issue-minimizing wand, it would probably go something like this:
  • Assuming that multiple shadow roots is the main source of uncertainty, determine what is blocking removal of multiple shadow roots and accelerate its removal. If there's just no way to investigate, maybe remove them on dev and beta for a few weeks just to find out what the top breakage is. Then set a reasonable date for removal and do it.

As far as I know, the main source of multiple shadow roots is still the old version of Polymer, if the situation does not change.

If old versions of Polymer vanished today, would it be possible to go ahead with deprecation/removal of multiple shadow roots right now, or would it also be blocked on shipping v1?

It would be possible, but I am not 100% sure, of course.
Removing multiple shadow roots is not a blocking issue to ship v1. I guess this is the root cause of misunderstanding, right?

 

  • Change attachShadow back to createShadowRoot with an optional ShadowRootInit argument, where open is the default mode. Deprecate and remove any remaining differences between ShadowRootType::V0 and ShadowRootType::Open where usage is low, and standardize the rest.
  • Change Event#path to FrozenArray<EventTarget> and standardize as-is, abandoning hope of renaming it to deepPath. (This assumes that the the local path is easily determined from the full path, and it looks like it is because the ShadowRoot is included.)
I'm not incredibly familiar with Shadow DOM so perhaps all of this is nonsense, but it seems like a gamble to hope that significant changes to what has been shipping for a very long time will work out. createShadowRoot and the current Event#path don't seem to be anywhere near broken enough to justify that risk.

Happy to learn more about this, and how others think this tricky situation should be handled.

Yeah, I am happy to answer your concerns. I appreciate if you could help me to handle this tricky situation.

Would you like me to file an issue to change attachShadow back to createShadowRoot, or do you personally prefer having them split even if it means keeping both forever? I think this comes down to how hard it is to merge "V0 and Open" into "V1 and Open".

Having said that the difference between v0 and v1 is *big*,  I am totally fine with having both, createShadowRoot() and attachShadow(), personally.

Given, 
1. (Parameterless) createShadowRoot() for v0
2. attachShadow(mandatoryInitDictionary) for v1.
3. createShadowRoot(mandatoryInitDictionary) for v1

I do not see a real difference between (1 and 2) and (1 and 3).
(1 and 2) looks less confusing to me.




Philip

Philip Jägenstedt

unread,
Mar 10, 2016, 3:36:17 AM3/10/16
to Hayato Ito, blink-dev
Yes, please do :)

A very blunt tool, which hasn't been tested, is to just remove things on the dev and beta channel for a few weeks at a time to collect reports of breakage. But you'd have no idea when you're getting close to the end of problems.

Hoping for a favorable outcome on https://github.com/w3c/webcomponents/issues/428 instead :)

Regarding createShadowRoot()/attachShadow(), I do not have any strong opinion on this *renaming*. As you said, we could choose to make createShadowRoot() take the extra argument, however, some of us thought that it might be simply confusing, and it would be better to have another name for v1 because v0 and v1 would have different semantics, AFAIR.

Did this difference in semantics become as big as anticipated? There are quite many places that check for ShadowRootType::V0, are all of those related to the already-deprecated behaviors of multiple shadow roots? In other words, if those bits are removed, is it within reach to fold V0 into the open mode?

No. They have different semantics. The following ShadowRootType's flags,

- V0
- Open
- Close

, are actually

- V0 and Open
- V1 and Open
- V1 and Close

, roughly.

To rephrase the question, if multiple shadow roots were removed, what would be the remaining differences between "V0 and Open" and "V1 and Open". If they are small then it looks hopeful that you could arrive at a single open mode, possibly by specifying some of the remaining quirks of "V0 and Open" for "V1 and Open" as well.


*New behavior of shadow trees* in the first post in this thread explains the differences between v0 and v1. That are the big differences.

Multiple shadow roots are just one of the differences. I guess I have omitted mentioning it in the first post because it was already deprecated and is irrelevant in shipping v1.

These mostly look like new features, possibly with the exception of "New CSS Cascading Order". Are new features like this actively prevented from working in v0, even in cases where they could work just fine?

So the question isn't merely the differences between "V0 and Open" and "V1 and Open", but what kinds of breakage of existing content you would expect if "V0 and Open" were instead treated as "V1 and Open". Can it really be that these two modes have diverges so much that merging them is hopelessly out of reach?

Conversely, if the differences are big, the obvious risk is that we'll just be stuck with three modes indefinitely.

Also, it looks like there aren't any use counters for <content> and <shadow>?

I never thought to have a use counter for <content>, however, I do not think we get much benefits by having a use counter for <content> for the purpose of deprecation because:
- It never happens to deprecate only <content>, without deprecating createShadowRoot(). That's unlikely.
- If we deprecate createShadowRoot(), that means we deprecate <content> too because <content> can not live without a createShadowRoot().

Regarding <shadow>, <shadow> should be always used together with multiple shadow roots feature, which has a use counter:

OK, I didn't know anything about these elements except how to spell them. Even if neither <content> nor <shadow> make any sense in the absence of createShadowRoot, it could still turn out that their usage is far smaller than that of createShadowRoot, and that they can be removed first. But if that doesn't strike you as a sane path to take, then of course there's no reason to add use counters just for the fun of it :)

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.


I totally agree on your concerns. Blink had to pay much cost to spread Shadow DOM into all browser vendors. If you have any idea to minimize our burden, let share it with us.

Perhaps promises have already been made to other browser vendors that make these ideas intractable, but if I could wave an interop- and compat-issue-minimizing wand, it would probably go something like this:
  • Assuming that multiple shadow roots is the main source of uncertainty, determine what is blocking removal of multiple shadow roots and accelerate its removal. If there's just no way to investigate, maybe remove them on dev and beta for a few weeks just to find out what the top breakage is. Then set a reasonable date for removal and do it.

As far as I know, the main source of multiple shadow roots is still the old version of Polymer, if the situation does not change.

If old versions of Polymer vanished today, would it be possible to go ahead with deprecation/removal of multiple shadow roots right now, or would it also be blocked on shipping v1?

It would be possible, but I am not 100% sure, of course.
Removing multiple shadow roots is not a blocking issue to ship v1. I guess this is the root cause of misunderstanding, right?

That is encouraging, no dependency either way between removing multiple shadow roots and shipping v1. I'm still not sure if I have understood or misunderstood the v0 vs. v1 situation as a whole :)

https://www.chromestatus.com/metrics/feature/timeline/popularity/779 is already pretty low, what do you think about setting a removal date like M55 right now, and sticking to that unless disaster strikes?

  • Change attachShadow back to createShadowRoot with an optional ShadowRootInit argument, where open is the default mode. Deprecate and remove any remaining differences between ShadowRootType::V0 and ShadowRootType::Open where usage is low, and standardize the rest.
  • Change Event#path to FrozenArray<EventTarget> and standardize as-is, abandoning hope of renaming it to deepPath. (This assumes that the the local path is easily determined from the full path, and it looks like it is because the ShadowRoot is included.)
I'm not incredibly familiar with Shadow DOM so perhaps all of this is nonsense, but it seems like a gamble to hope that significant changes to what has been shipping for a very long time will work out. createShadowRoot and the current Event#path don't seem to be anywhere near broken enough to justify that risk.

Happy to learn more about this, and how others think this tricky situation should be handled.

Yeah, I am happy to answer your concerns. I appreciate if you could help me to handle this tricky situation.

Would you like me to file an issue to change attachShadow back to createShadowRoot, or do you personally prefer having them split even if it means keeping both forever? I think this comes down to how hard it is to merge "V0 and Open" into "V1 and Open".

Having said that the difference between v0 and v1 is *big*,  I am totally fine with having both, createShadowRoot() and attachShadow(), personally.

Given, 
1. (Parameterless) createShadowRoot() for v0
2. attachShadow(mandatoryInitDictionary) for v1.
3. createShadowRoot(mandatoryInitDictionary) for v1

I do not see a real difference between (1 and 2) and (1 and 3).
(1 and 2) looks less confusing to me.

What I mean is a createShadowRoot(optionalInitDictionary) where omitting the argument gets the v0 behavior. But this is assuming that merging v0 into the v1 open mode is within reach. If it really isn't, then I don't know what would be best in the long term.

At a high level, part of the risk may come from the commitment to maintaining v0 behavior while implementing v1. Because it's hoped that v0 will not be around in 10 years, differences between v0 and v1 open are not a big problem. However, this may allow the differences to grow, which would in turn increases the risk that v0 stays around as a third mode indefinitely. Maybe this isn't an accurate characterization, clearly there are many details I'm ignorant about.

Philip

Hayato Ito

unread,
Mar 14, 2016, 6:37:42 AM3/14/16
to Philip Jägenstedt, blink-dev
Merging them is unrealistic. That is not the design goal of v1. That is the opposite direction of what we have been doing.
After the f2f meeting in the last year, we, browser vendors, have been spending our efforts to evolve v1 APIs, where no one has not taken care of the compatibility of current v0 API. That's the exactly the reason we wanted to have a new API, attachShadow(), to make our goal clear.

So I can say merging them is hopelessly out of reach because it would revert our recent efforts in the last year.

 
Conversely, if the differences are big, the obvious risk is that we'll just be stuck with three modes indefinitely.

Also, it looks like there aren't any use counters for <content> and <shadow>?

I never thought to have a use counter for <content>, however, I do not think we get much benefits by having a use counter for <content> for the purpose of deprecation because:
- It never happens to deprecate only <content>, without deprecating createShadowRoot(). That's unlikely.
- If we deprecate createShadowRoot(), that means we deprecate <content> too because <content> can not live without a createShadowRoot().

Regarding <shadow>, <shadow> should be always used together with multiple shadow roots feature, which has a use counter:

OK, I didn't know anything about these elements except how to spell them. Even if neither <content> nor <shadow> make any sense in the absence of createShadowRoot, it could still turn out that their usage is far smaller than that of createShadowRoot, and that they can be removed first. But if that doesn't strike you as a sane path to take, then of course there's no reason to add use counters just for the fun of it :)

I'm sorry that all of this is a bit off-topic for Shadow DOM v1. It's great that this work is proceeding, and here I'm only focusing on the details with potential for compat and interop fallout.


I totally agree on your concerns. Blink had to pay much cost to spread Shadow DOM into all browser vendors. If you have any idea to minimize our burden, let share it with us.

Perhaps promises have already been made to other browser vendors that make these ideas intractable, but if I could wave an interop- and compat-issue-minimizing wand, it would probably go something like this:
  • Assuming that multiple shadow roots is the main source of uncertainty, determine what is blocking removal of multiple shadow roots and accelerate its removal. If there's just no way to investigate, maybe remove them on dev and beta for a few weeks just to find out what the top breakage is. Then set a reasonable date for removal and do it.

As far as I know, the main source of multiple shadow roots is still the old version of Polymer, if the situation does not change.

If old versions of Polymer vanished today, would it be possible to go ahead with deprecation/removal of multiple shadow roots right now, or would it also be blocked on shipping v1?

It would be possible, but I am not 100% sure, of course.
Removing multiple shadow roots is not a blocking issue to ship v1. I guess this is the root cause of misunderstanding, right?

That is encouraging, no dependency either way between removing multiple shadow roots and shipping v1. I'm still not sure if I have understood or misunderstood the v0 vs. v1 situation as a whole :)

https://www.chromestatus.com/metrics/feature/timeline/popularity/779 is already pretty low, what do you think about setting a removal date like M55 right now, and sticking to that unless disaster strikes?

Sure. I am fine with setting a removal date, as a tentative plan. Done at https://www.chromestatus.com/features/4769966083538944

 

  • Change attachShadow back to createShadowRoot with an optional ShadowRootInit argument, where open is the default mode. Deprecate and remove any remaining differences between ShadowRootType::V0 and ShadowRootType::Open where usage is low, and standardize the rest.
  • Change Event#path to FrozenArray<EventTarget> and standardize as-is, abandoning hope of renaming it to deepPath. (This assumes that the the local path is easily determined from the full path, and it looks like it is because the ShadowRoot is included.)
I'm not incredibly familiar with Shadow DOM so perhaps all of this is nonsense, but it seems like a gamble to hope that significant changes to what has been shipping for a very long time will work out. createShadowRoot and the current Event#path don't seem to be anywhere near broken enough to justify that risk.

Happy to learn more about this, and how others think this tricky situation should be handled.

Yeah, I am happy to answer your concerns. I appreciate if you could help me to handle this tricky situation.

Would you like me to file an issue to change attachShadow back to createShadowRoot, or do you personally prefer having them split even if it means keeping both forever? I think this comes down to how hard it is to merge "V0 and Open" into "V1 and Open".

Having said that the difference between v0 and v1 is *big*,  I am totally fine with having both, createShadowRoot() and attachShadow(), personally.

Given, 
1. (Parameterless) createShadowRoot() for v0
2. attachShadow(mandatoryInitDictionary) for v1.
3. createShadowRoot(mandatoryInitDictionary) for v1

I do not see a real difference between (1 and 2) and (1 and 3).
(1 and 2) looks less confusing to me.

What I mean is a createShadowRoot(optionalInitDictionary) where omitting the argument gets the v0 behavior. But this is assuming that merging v0 into the v1 open mode is within reach. If it really isn't, then I don't know what would be best in the long term.

At a high level, part of the risk may come from the commitment to maintaining v0 behavior while implementing v1. Because it's hoped that v0 will not be around in 10 years, differences between v0 and v1 open are not a big problem. However, this may allow the differences to grow, which would in turn increases the risk that v0 stays around as a third mode indefinitely. Maybe this isn't an accurate characterization, clearly there are many details I'm ignorant about.


It is not the design goal of V1 to make the difference between v0 and v1 minimize, as I mentioned before. We abandoned such a hope at the f2f meeting in the last year.
After the f2f meeting, we have spent much efforts to make v1 APIs better and better without looking back at v0.

I think this topic is not what Blink can decide. I think https://github.com/w3c/webcomponents/issues/129 is the issue to be re-opened, if necessary.

 
Philip

Hayato Ito

unread,
Mar 14, 2016, 6:39:48 AM3/14/16
to Philip Jägenstedt, blink-dev
Ops. One correction is:

s/where no one has not taken care of the compatibility of current v0 APIs/where no one has taken care of the compatibility of current v0 APIs/

Philip Jägenstedt

unread,
Mar 23, 2016, 12:36:10 AM3/23/16
to Hayato Ito, blink-dev
OK, so I gave up on https://github.com/w3c/webcomponents/issues/428 since it was going nowhere.

The basic idea was to reduce risk by getting rid of differences between v0 and v1, but it looks like I'm much too late to the party, with this having been agreed upon at last year's f2f.

I think the best hope for interop is now to be as aggressive as possible in removing v0, where Blink should be willing to take larger compat risk than usual to achieve that.

In the case of path/deepPath, is there any reason to not ship deepPath() immediately, so that people can transition to using that ASAP? The implementation is the same except NonEmptyAfterDispatch/EmptyAfterDispatch, after all.

Hayato Ito

unread,
Mar 23, 2016, 1:02:43 AM3/23/16
to Philip Jägenstedt, blink-dev
On Wed, Mar 23, 2016 at 1:36 PM Philip Jägenstedt <phi...@opera.com> wrote:
OK, so I gave up on https://github.com/w3c/webcomponents/issues/428 since it was going nowhere.

The basic idea was to reduce risk by getting rid of differences between v0 and v1, but it looks like I'm much too late to the party, with this having been agreed upon at last year's f2f.

I think the best hope for interop is now to be as aggressive as possible in removing v0, where Blink should be willing to take larger compat risk than usual to achieve that.


Yeah, I agree strongly.
 
In the case of path/deepPath, is there any reason to not ship deepPath() immediately, so that people can transition to using that ASAP? The implementation is the same except NonEmptyAfterDispatch/EmptyAfterDispatch, after all.

Yeah, that was the motivation that I sent "Intent to Implement and Ship: Event.deepPath", but it did not get LGTMed: See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/8_x0OHYQdx0
Do you think it is worth to send again? IMO, I would like to wait for a couple of months to feel that the spec of deepPath() is stable enough.

Philip Jägenstedt

unread,
Mar 23, 2016, 1:37:40 AM3/23/16
to Hayato Ito, blink-dev
On Wed, Mar 23, 2016 at 12:02 PM, Hayato Ito <hay...@chromium.org> wrote:


On Wed, Mar 23, 2016 at 1:36 PM Philip Jägenstedt <phi...@opera.com> wrote:
OK, so I gave up on https://github.com/w3c/webcomponents/issues/428 since it was going nowhere.

The basic idea was to reduce risk by getting rid of differences between v0 and v1, but it looks like I'm much too late to the party, with this having been agreed upon at last year's f2f.

I think the best hope for interop is now to be as aggressive as possible in removing v0, where Blink should be willing to take larger compat risk than usual to achieve that.


Yeah, I agree strongly.
 
In the case of path/deepPath, is there any reason to not ship deepPath() immediately, so that people can transition to using that ASAP? The implementation is the same except NonEmptyAfterDispatch/EmptyAfterDispatch, after all.

Yeah, that was the motivation that I sent "Intent to Implement and Ship: Event.deepPath", but it did not get LGTMed: See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/8_x0OHYQdx0
Do you think it is worth to send again? IMO, I would like to wait for a couple of months to feel that the spec of deepPath() is stable enough.

It was I who derailed that Intent to Ship with the same concerns about ending up with both path and deepPath, and it ended with a desire to understand more about the usage of path. I'm not sure if anyone has a good understanding of its usage in the wild yet, but we can be pretty sure that the use counter is tainted by enumeration, which wasn't mentioned at the time.

At this point, I think that even if true usage of event.path were 2%, the only way forward would still be to ship deepPath(), so this time around I would say LGTM. So as soon as you think the spec is in good shape and unlikely to change again, a new Intent to Ship deepPath() sounds like a good idea.

Philip

PhistucK

unread,
Mar 25, 2016, 8:42:53 AM3/25/16
to Hayato Ito, Philip Jägenstedt, blink-dev

On Mon, Mar 14, 2016 at 1:37 PM, Hayato Ito <hay...@chromium.org> wrote:
Sure. I am fine with setting a removal date, as a tentative plan. Done at https://www.chromestatus.com/features/4769966083538944

No one will read the description so far... ​You should put the removal date or version in the deprecation warning string.​



☆PhistucK
Reply all
Reply to author
Forward
0 new messages