Intent to Ship: Shadow DOM

2,140 views
Skip to first unread message

Kenji Baheux

unread,
Feb 3, 2014, 3:07:30 PM2/3/14
to blink-dev

Primary eng (and PM) emails

hay...@chromium.org  (kenji...@chromium.org)


Spec

http://w3c.github.io/webcomponents/spec/shadow/


Summary

Shadow DOM lets developers establish and maintain functional boundaries between DOM trees and how these trees interact with each other within a document, thus enabling better functional encapsulation within the DOM.


Link to “Intent to Implement” blink-dev discussion

N/A (the implementation started before blink).

Motivation

Shadow DOM is one of the four Web Components API. Web Components make it possible to build widgets which can be reused reliably and makes worrying about adverse effect of internal implementation details changes an irrelevant issue.


Shadow DOM solves the third aspect mentioned above, namely the DOM tree encapsulation problem. In other words, Shadow DOM makes development of complex web apps sane by allowing developers reason about the parts of the app separately while at the same time maintaining the whole of the app.


We put a lot of effort into designing this specification in W3C WebApps Working Group, we built polyfills and invested a ton more of effort into real-life usefulness of Shadow DOM (by building Polymer on top of it).



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

Yes.


Demo link

Shadow DOM 101

Shadow DOM 201

Shadow DOM 301

and Polymer apps.


Compatibility Risk

Shadow DOM is a bucket 4 item: “The specification for the feature has been accepted by the appropriate standards working group (e.g., a First Public Working Draft in the W3C) and we’ve received positive feedback from other browser engines about the feature’s feasibility and value.” Concretely, Mozilla is actively implementing Shadow DOM.


Note: we shipped a prefixed implementation of Shadow DOM in Chrome 25 which was before Blink times. This implementation is now obsolete in significant terms. This very situation is bad for compatibility. We learned a lot in the process and we believe that we are in a much more stable situation on both spec and implementation aspects. We will simultaneously unship the prefixed implementation of Shadow DOM.



OWP launch tracking bug?

http://crbug.com/336121


Link to entry on the feature dashboard

http://www.chromestatus.com/features/4507242028072960


Alex Russell

unread,
Feb 3, 2014, 8:37:24 PM2/3/14
to Kenji Baheux, blink-dev
I couldn't be more excited about this. Great work, all!


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

Adam Barth

unread,
Feb 5, 2014, 1:15:54 AM2/5/14
to Kenji Baheux, blink-dev
I spent some time reading this thread on www-style this evening:


It's pretty long, and I'll admit to not having read the whole thing, but some folks on that thread raise some concerns about how shipping this feature fits into Blink's compatibility guidelines.  That discussion is somewhat out of scope for www-style, but it might be worth replying to those concerned on this mailing list.  They might not wish to continue that discussion in this forum, but we should at least invite them.

Adam


On Mon, Feb 3, 2014 at 12:07 PM, Kenji Baheux <kenji...@chromium.org> wrote:

Jeffrey Yasskin

unread,
Feb 5, 2014, 1:55:55 AM2/5/14
to Adam Barth, Elliott Sprehn, Kenji Baheux, blink-dev
www-style seems right that ^ and ^^ are un-specced, unlike the rest of
shadow-dom: http://w3c.github.io/webcomponents/spec/shadow/#h_issue_6.
http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/#toc-style-cat
is the only public documentation, and AFAIU, it's incorrect. As
discussed in https://groups.google.com/d/topic/polymer-dev/g1-72AA7EO4/discussion,
this makes it hard for users to know whether a behavior is a bug or
expected.

I don't know if performance foot-guns are in scope for this thread,
but Elliott mentioned that using 2 ^^s in a selector causes O(n^2)
behavior. (I'm not sure what 'n' is in that running time.) Since ^^s
look so useful for forcing properties onto elements, that worries me.

Ryosuke Niwa

unread,
Feb 5, 2014, 3:03:28 AM2/5/14
to Adam Barth, Kenji Baheux, blink-dev
On Tue, Feb 4, 2014 at 10:15 PM, Adam Barth <aba...@chromium.org> wrote:
I spent some time reading this thread on www-style this evening:


It's pretty long, and I'll admit to not having read the whole thing, but some folks on that thread raise some concerns about how shipping this feature fits into Blink's compatibility guidelines.  That discussion is somewhat out of scope for www-style, but it might be worth replying to those concerned on this mailing list.  They might not wish to continue that discussion in this forum, but we should at least invite them.


I'll reply once since I'm not in a position to comment on whether Blink should or should not ship a feature.


FWIW, Mozilla is implementing the feature in order to gather feedback from developers as pointed out by Blake Kaplan here:

Blake says "we're definitely not even close to a position where we'd
like to freeze anything" and "I expect that we are also going to see at least a few other things once document.register is properly useable and starts getting tested."


Apple has expressed concerns over insertion points and multiple generations of shadow DOMs repeatedly in the WebApps working group.


In addition, neither Mozilla nor Apple had been able to review custom elements specifications in late November/early December time frame: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0718.html
and Apple has specifically expressed concerns over not moving shadow DOM and custom element specifications forward at the same time.


- R. Niwa

Dimitri Glazkov

unread,
Feb 5, 2014, 3:37:51 PM2/5/14
to Adam Barth, Kenji Baheux, blink-dev
Given the response from Mozilla on the thread: http://lists.w3.org/Archives/Public/www-style/2014Feb/0098.html, we should upgrade the compatibility risk from bucket 4 to an exception: http://dev.chromium.org/blink/#TOC-Exceptions

The way I see it, the main risk is that Shadow DOM spec (and surrounding parts) will change in a way that would force Blink to choose between breaking compatibility with existing content and new behavior.

Should we take this risk? Damn good question. Here's how I see it:

* Without the native Shadow DOM support, we simply won't get good performance numbers from Polymer or any other JS frameworks that rely on Web Components, _especially_ on mobile and _especially_ for the CSS features. They are the hardest to polyfill in a performant manner.

* The majority of Shadow DOM plumbing (both implementation and spec-wise) had settled down and remained unchanged for a while (a year?).

* Remaining spec/implementation issues are things we can (and should) resolve expeditiously, within one or two iteration of shipping.

* Given that Polymer will be the primary consumer of the implementation (at least initially), we have a pretty high degree of insulating the user from the changes in iterations.

We do need to get CSS features well-specified and keep making progress on the spec.

With a feature as large as Shadow DOM, shipping is not the end, it's just the beginning of a journey. We are well-prepared (as prepared as we'll ever be) to accommodate any potential spec changes. And we gotta start walking.

:DG<

Adam Barth

unread,
Feb 5, 2014, 3:58:39 PM2/5/14
to Dimitri Glazkov, Kenji Baheux, blink-dev
I think a question someone might ask reading the recent discussions on this mailing is "what's difference between Shadow DOM and CSS Regions?"  On the surface, both seem like large, complex features that have broad implications for the code base.  The former has broad implications for the DOM whereas the latter has broad implications for the render tree.

It's also worth pointing out that there's an important difference between shipping this feature under the usual compatibility guidelines and shipping the feature using the exception clause.  Specifically, the exception clause says "we will take on an active commitment to shepherd the feature through the standards process, accepting the burden of possible API changes" [1].  That's somewhat different from what Tab said on www-style: "whatever API gets shipped will be frozen almost immediately" [2].

Adam

Alex Russell

unread,
Feb 5, 2014, 4:08:50 PM2/5/14
to Adam Barth, Dimitri Glazkov, Kenji Baheux, blink-dev
On Wed, Feb 5, 2014 at 12:58 PM, Adam Barth <aba...@chromium.org> wrote:
I think a question someone might ask reading the recent discussions on this mailing is "what's difference between Shadow DOM and CSS Regions?"  On the surface, both seem like large, complex features that have broad implications for the code base.  The former has broad implications for the DOM whereas the latter has broad implications for the render tree.

The difference is that Shadow DOM explains current behvaior (e.g., of <video> and <button> elements). Providing power to authors that is currently reserved for the UA (but is expressed none the less) and is part of a balanced diet when creating a layered platform.
 
It's also worth pointing out that there's an important difference between shipping this feature under the usual compatibility guidelines and shipping the feature using the exception clause.  Specifically, the exception clause says "we will take on an active commitment to shepherd the feature through the standards process, accepting the burden of possible API changes" [1].  That's somewhat different from what Tab said on www-style: "whatever API gets shipped will be frozen almost immediately" [2].

Is it a difference with distinction? Accepting the burden of possible changes is something one can do while also acknowledging that the more use a feature has, the harder it is to rescind it.
 
Adam

[1] http://dev.chromium.org/blink#TOC-Exceptions
[2] http://lists.w3.org/Archives/Public/www-style/2014Feb/0036.html



On Wed, Feb 5, 2014 at 12:37 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:
Given the response from Mozilla on the thread: http://lists.w3.org/Archives/Public/www-style/2014Feb/0098.html, we should upgrade the compatibility risk from bucket 4 to an exception: http://dev.chromium.org/blink/#TOC-Exceptions

The way I see it, the main risk is that Shadow DOM spec (and surrounding parts) will change in a way that would force Blink to choose between breaking compatibility with existing content and new behavior.

Should we take this risk? Damn good question. Here's how I see it:

* Without the native Shadow DOM support, we simply won't get good performance numbers from Polymer or any other JS frameworks that rely on Web Components, _especially_ on mobile and _especially_ for the CSS features. They are the hardest to polyfill in a performant manner.

* The majority of Shadow DOM plumbing (both implementation and spec-wise) had settled down and remained unchanged for a while (a year?).

* Remaining spec/implementation issues are things we can (and should) resolve expeditiously, within one or two iteration of shipping.

* Given that Polymer will be the primary consumer of the implementation (at least initially), we have a pretty high degree of insulating the user from the changes in iterations.

We do need to get CSS features well-specified and keep making progress on the spec.

With a feature as large as Shadow DOM, shipping is not the end, it's just the beginning of a journey. We are well-prepared (as prepared as we'll ever be) to accommodate any potential spec changes. And we gotta start walking.

:DG<

Dimitri Glazkov

unread,
Feb 5, 2014, 4:37:36 PM2/5/14
to Alex Russell, Adam Barth, Kenji Baheux, blink-dev
On Wed, Feb 5, 2014 at 1:08 PM, Alex Russell <sligh...@google.com> wrote:
On Wed, Feb 5, 2014 at 12:58 PM, Adam Barth <aba...@chromium.org> wrote:
I think a question someone might ask reading the recent discussions on this mailing is "what's difference between Shadow DOM and CSS Regions?"  On the surface, both seem like large, complex features that have broad implications for the code base.  The former has broad implications for the DOM whereas the latter has broad implications for the render tree.

The difference is that Shadow DOM explains current behvaior (e.g., of <video> and <button> elements). Providing power to authors that is currently reserved for the UA (but is expressed none the less) and is part of a balanced diet when creating a layered platform.

I'd tack on one more: we need a sound component model to build modern mobile apps. Shadow DOM is the foundational part of such a component model (aka Web Components), and so it aligns well with Blink priorities. If Blink was primarily interested in building amazing interactive books and magazines in 2014, it's less clear that Shadow DOM would be worth working on.

:DG<

Erik Bryn

unread,
Feb 5, 2014, 9:24:04 PM2/5/14
to blin...@chromium.org, Adam Barth, Kenji Baheux
On Wednesday, February 5, 2014 12:37:51 PM UTC-8, Dimitri Glazkov wrote:
> * Without the native Shadow DOM support, we simply won't get good performance numbers from Polymer or any other JS frameworks that rely on Web Components, _especially_ on mobile and _especially_ for the CSS features. They are the hardest to polyfill in a performant manner.

Out of curiosity, do you know of any JS frameworks other than Polymer that rely on Web Components?

- Erik

Eric Bidelman

unread,
Feb 5, 2014, 10:00:28 PM2/5/14
to Erik Bryn, blink-dev, Adam Barth, Kenji Baheux
There's a growing list here: https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%3F. It's also worth noting that in the Dart space, Polymer.dart uses the polyfils and Angular.dart creates directives using native Shadow DOM.



Daniel Freedman

unread,
Feb 5, 2014, 10:34:32 PM2/5/14
to Erik Bryn, blink-dev, Adam Barth, Kenji Baheux
Mozilla's Brick relies on Web Components, though not Shadow DOM at the moment. I believe this is due in part to the lack of a completed ShadowDOM implementation on Mozilla's side.

Ember and Angular both have plans in place to start supporting Web Components.

It's important to remember that there's a chicken and egg problem here: Frameworks can't start supporting what they can't play with.

ShadowDOM is such a powerful new feature (and one that's incredibly hard to polyfill) that I wouldn't expect any other group to take serious interest until it has shipped in the wild. Not behind a flag, not in a canary or beta version, only in something everyone can use.

The Polymer team is in a unique position of being embedded directly in the Chrome team, so we can have a much more rapid iteration cycle between the specifications and native implementation, while arguing for what makes the most sense for developers at large.


On Wed, Feb 5, 2014 at 6:24 PM, Erik Bryn <erik...@gmail.com> wrote:

PhistucK

unread,
Feb 6, 2014, 2:22:45 PM2/6/14
to Daniel Freedman, Erik Bryn, blink-dev, Adam Barth, Kenji Baheux
While Polymer can update fast (I think this is what you were suggesting), developers may not always update to the latest version.
jQuery 1.7 is hugely popular, for example and it is two and a half years old.


PhistucK


Daniel Freedman

unread,
Feb 6, 2014, 2:28:25 PM2/6/14
to PhistucK, Erik Bryn, blink-dev, Adam Barth, Kenji Baheux
I was actually suggesting that Polymer could adapt with the changes to the Shadow DOM implementation and give important feedback quickly.
This is vitally important to making sure we ship a usable feature.
To ask other frameworks to be able to adapt that quickly seems wholly unfair to their time and effort, and any that do follow along have my sympathy and respect.
Once we ship ShadowDOM, it shouldn't change that fast, allowing other frameworks to embrace the abilities.

Alex Russell

unread,
Feb 6, 2014, 2:30:36 PM2/6/14
to PhistucK, Daniel Freedman, Erik Bryn, blink-dev, Adam Barth, Kenji Baheux
On Thu, Feb 6, 2014 at 11:22 AM, PhistucK <phis...@gmail.com> wrote:
While Polymer can update fast (I think this is what you were suggesting), developers may not always update to the latest version.
jQuery 1.7 is hugely popular, for example and it is two and a half years old.

It's unclear how that's relevant to the current discussion. JQuery became popular on the back of much iteration (early versions broke selector compatibility between sub-point releases).

What matters is that we are able to iterate in the growth phase for the technology in ways that are responsive to developer needs. It's my view that this flexibility is preserved by the current proposal.

Regards

Eric Seidel

unread,
Feb 6, 2014, 7:58:16 PM2/6/14
to Alex Russell, PhistucK, Daniel Freedman, Erik Bryn, blink-dev, Adam Barth, Kenji Baheux
Reading the www-style thread made me realize that one reason the CSS
WG might like prefixes is that they prevent vendors from pooping on
the global namespace. Once we ship ^^ someone else later using that
name to mean something else is much harder. To implementors, prefixed
or not is largely the same, since once any feature gets above a
certain usage we have to maintain it forever regardless of the naming.


Dimitri wrote:
> * Given that Polymer will be the primary consumer of the implementation (at least initially), we have a pretty high degree of insulating the user from the changes in iterations.

I don't agree. We don't (currently) have any way to tell the
difference between polymer uses of these APIs and any random website.
Once any usage (polymer or otherwise) goes above 0.06% of Chrome page
loads we can't easily change these APIs as we don't know who's using
them.

> We do need to get CSS features well-specified and keep making progress on the spec.

Agreed. One of the benefits of the web platform is its ubiquity and
compatibility. It's important for other implementors to be able to
run the same apps/content.


The web hasn't historically been particularly good at the spec-first,
ship-later ideal, but we've tried to hold ourselves to such more
recently. <canvas> comes to mind as an example and like shadow-dom was
also something the web absolutely needed at the time. Given how
important custom-element encapsulation seems to making maintainable
web apps, I'm willing to see us make exceptions to our process to move
forward here expediently.


Is there any use in shipping the more-well-specified and seemingly
less controversial DOM bits of Shadow DOM w/o the CSS bits? Or is ^
and ^^ integral to any real Shadow DOM usage?

Alex Russell

unread,
Feb 6, 2014, 9:01:23 PM2/6/14
to Eric Seidel, PhistucK, Daniel Freedman, Erik Bryn, blink-dev, Adam Barth, Kenji Baheux
No.

Kenji Baheux

unread,
Feb 12, 2014, 4:10:13 AM2/12/14
to blin...@chromium.org, Eric Seidel, PhistucK, Daniel Freedman, Erik Bryn, Adam Barth, Kenji Baheux
Implementation update:
We are currently addressing the feedback from the CSS WG. Concretely, we are updating the implementation to match the proposed alternative to ^ and ^^ as detailed in http://dev.w3.org/csswg/shadow-styling/ 

The intent to ship will be resumed as soon as the implementation rework is done which should not take too long.
Message has been deleted

Adam Barth

unread,
Mar 10, 2014, 10:55:43 AM3/10/14
to kenji...@google.com, blin...@chromium.org, ese...@chromium.org, phis...@gmail.com, dfr...@chromium.org, erik...@gmail.com, aba...@chromium.org, kenji...@chromium.org
On Mon Mar 10 2014 at 12:31:18 AM, <kenji...@google.com> wrote:
There was one more round of discussion about the alternative to Cat ^ and Hat ^^ which delayed the implementation change.
The CL to rename ^ and ^^ selectors in accordance with the spec's /shadow/ and /shadow-deep/ is still under review but is being hold on for an unrelated nit.
We are confident that the CL will land shortly.

Therefore, I would like to resume the intent to ship Shadow DOM.

Two questions:

1) Are you still intending to ship under the exception clause?  The reason I ask is because the process for the exception clause is a bit different (e.g., the API OWNERS are required to meet face-to-face and the project incurs an obligation to track the specs as they evolve in the standards process).

2) One concern raised in the previous thread was that not everything we were considering shipping was written down in specifications.  For example, the CSS combinators were documented informally but we hadn't written a formal specification for them.  Have we published specifications for all the behavior your intend to ship?  If so, would you be willing to provide links to those specifications?

Thanks,
Adam
 

Tab Atkins Jr.

unread,
Mar 10, 2014, 5:41:23 PM3/10/14
to Adam Barth, Kenji Baheux, blink-dev, Eric Seidel, Alon Gothshmidt, dfr...@chromium.org, erik...@gmail.com, Adam Barth, Kenji Baheux
On Mon, Mar 10, 2014 at 7:55 AM, Adam Barth <aba...@google.com> wrote:
> 2) One concern raised in the previous thread was that not everything we were
> considering shipping was written down in specifications. For example, the
> CSS combinators were documented informally but we hadn't written a formal
> specification for them. Have we published specifications for all the
> behavior your intend to ship? If so, would you be willing to provide links
> to those specifications?

Yup, been out in public for several weeks now, almost immediately
after we were called out on it:
http://dev.w3.org/csswg/shadow-styling/

It's still undergoing slight tweaking here and there, but I consider
it pretty stable and am ready to track implementations as necessary.

~TJ
Message has been deleted

Kenji Baheux

unread,
Mar 12, 2014, 4:52:52 PM3/12/14
to blin...@chromium.org

As Tab said, we now have a solid spec [1] for the CSS side of Shadow DOM. It went through a couple of changes based on feedback Tab got from the CSS working group. The implementation has already caught up. Hayato also finished the refactoring of the Shadow DOM spec.


Since Mozilla is actively working on their own Shadow DOM implementation, we were able to discuss in depth the different questions and have them be our sounding board. Their implementation is in early stages and they haven't had the chance to gather feedback from the developers yet. However, their assessment matches ours: there's probably more work to be done on Shadow DOM, but the majority of it will be additive to the existing core. This is also captured in the spec evolution plan [2].



As a closing remark, we are committed to ensure compatibility among implementations. We have been updating the w3c Shadow DOM test suite [3] as the changes were made to the specs (adjusting existing tests and adding new tests; 18 pull requests have been merged and 22 additional pull requests are in the pipeline).


[1]: http://dev.w3.org/csswg/shadow-styling/

[2]: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0338.html

[3]: https://github.com/w3c/web-platform-tests/tree/master/shadow-dom

Eric Seidel

unread,
Mar 18, 2014, 2:05:22 PM3/18/14
to Kenji Baheux, blink-dev
I'd like to confirm my understanding of exactly which APIs are under
discussion for shipping at this time.

New DOM APIs from http://w3c.github.io/webcomponents/spec/shadow/

Element.createShadowRoot
Element.shadowRoot

ShadowRoot.getElementById
ShadowRoot.getElementsByClassName
ShadowRoot.getElementsByTagName
ShadowRoot.getElementsByTagNameNS
ShadowRoot.getSelection
ShadowRoot.elementFromPoint
ShadowRoot.activeElement
ShadowRoot.host
ShadowRoot.olderShadowRoot
ShadowRoot.innerHTML
ShadowRoot.styleSheets

Event.relatedTarget


New CSS APIs, from http://dev.w3.org/csswg/shadow-styling/

/shadow
/shadow-deep
/content

:host
:top
:ancestor
:shadow


Am I correct in understanding that this is the API surface which is
being proposed for shipping?

PhistucK

unread,
Mar 18, 2014, 2:32:05 PM3/18/14
to Eric Seidel, Kenji Baheux, blink-dev
I was under the impression that getElementsByX (and especially getElementsByTagNameNS) are legacy methods that have performance implications and are not preferred and would have gone away if they were not used that much (but they are). Unless my impression is incorrect, why is there support for these methods in a new API (and where are querySelector and querySelectorAll)?


PhistucK


Daniel Freedman

unread,
Mar 18, 2014, 2:45:47 PM3/18/14
to PhistucK, Eric Seidel, Kenji Baheux, blink-dev
ShadowRoot implements DocumentFragment, which already has querySelector and querySelectorAll.

Hayato Ito

unread,
Mar 19, 2014, 2:59:39 AM3/19/14
to Eric Seidel, Kenji Baheux, blink-dev
At this time, we are shipping the following APIs, which had been guarded by the flag (RuntimeEnabled=ShadowDOM).



Element.createShadowRoot
Element.shadowRoot
Element.getDestinationInsertionPoints

ShadowRoot.host
ShadowRoot.styleSheets
ShadowRoot.olderShadowRoot

ShadowElement.getDistributedNodes

Event.path



/shadow
/shadow-deep
/content

:host
:top
:ancestor
:shadow

--
Hayato

Adam Barth

unread,
Mar 19, 2014, 12:49:58 PM3/19/14
to Hayato Ito, Eric Seidel, Kenji Baheux, blink-dev
To clarify: these APIs are enabled provisionally on trunk to let them bake for a while.

Adam Barth

unread,
Mar 20, 2014, 2:30:45 PM3/20/14
to Kenji Baheux, blink-dev

Summary

On Tuesday, the API owners met to discuss the intent to ship Shadow DOM.  We've decided to ship Shadow DOM under guideline #4.


Compatibility risk

Compatibility risk is one of the most important decision criteria for enabling new web platform features by default. This section discusses the compatibility risk factors of shipping Shadow DOM at this time:


  • Other vendors shipping compatible implementations.  Currently no other vendors are shipping compatible implementations of Shadow DOM.

    • Mozilla has provided positive feedback about the feature and is currently implementing Shadow DOM behind a runtime flag.  Based on these discussions, Mozilla appears to be on track to ship a compatible implementation at some point in the future.

    • Apple has participated in the standards discussion about Shadow DOM and has expressed some concerns about several aspects of the feature (see below for further discussion).  They’ve announced an intent to implement Shadow DOM on a branch to assess the performance implications.  Based on these discussions, there appears to be a non-trivial risk that Apple will ship an incompatible implementation at some point in the future.

  • A mature specification in the relevant standards body.  This feature has two main specifications, Shadow DOM and Shadow DOM Styling, which are being discussed by the W3C WebApps and W3C CSS working groups, respectively.

    • The core Shadow DOM specification was first published as a working draft in May 2012 and has evolved over the years based on feedback from the working group and from web developers using Shadow DOM.

    • The Shadow DOM Styling specification is more recent, having originally been part of the core Shadow DOM specification.

  • Positive signals from other browser vendors.  Microsoft has provided some public feedback about Shadow DOM in the W3C.  Their feedback has generally been positive, but they have not committed to implementing the feature.

  • A small API footprint.  Shadow DOM has a modest API footprint when viewed in terms of the number of new properties, functions, and CSS syntax, but behind those new entry points, Shadow DOM exposes a rich view on the internal structure of the DOM.

Controversy

The core concepts that underlie Shadow DOM are well established in the web platform because most browser engines already use these concepts internally to implement existing HTML features, such as HTMLInputElement.  However, Shadow DOM exposes these powerful tools to web developers, which raise some issues that browser vendors have not needed to resolve in their internal uses of shadow-like DOM.


  • Encapsulation.  One controversial issue is whether Shadow DOM ought to be an encapsulation mechanism.  For example, Maciej Stachowiak raised this issue in the WebApps working group in 2011.  The Shadow DOM browser vendors use internally has encapsulation, which is why web developers cannot poke at the internal DOM structure of the HTMLInputElement.  As Dimitri Glazkov explained in The Shadow DOM Diaries, the goal of Shadow DOM is to provide composition and encapsulation is just a tool that might be useful in providing composition.

  • Distribution.  Another controversial issue is how to handle the distribution of light child in the composed tree, first raised in August 2012.  Again, this is an area in which browser implementers don’t have much experience because the internal uses of Shadow DOM in browser involve only one level of composition.  The difficult cases for distribution arise when nested components are fighting over the distribution of children from the lightest DOM.

Implementation experience

These controversies add risk to shipping Shadow DOM for two reason: (1) different browser vendors might ship incompatible implementations that take different positions on these topics, and (2) Shadow DOM might take a position on these topics that isn't what web developers want.


To help reduce the first type of risk, we've been in active discussions with other browser vendors about Shadow DOM for over three years in the W3C.  These topics are complex and take time to discuss thoroughly, but at some point we need to move beyond in-principle discussions to in-practice discussions informed by the experience of real web developers using Shadow DOM.


To gain that implementation experience, and to reduce the second type of risk, the Blink developers working on Shadow DOM have been deeply engaged with the Polymer team, which is using web components (and Shadow DOM specifically) to build a web framework, a set of components, and a number of example applications.  Over time, the experience of these web developers has helped guide the evolution of Shadow DOM towards something that’s hopefully useful for web developers more broadly.


Guidelines

Shadow DOM appears to qualify for shipping under guideline #4. The specification for the feature has been accepted by the appropriate standards working group (i.e., a Working Draft in the W3C WebApps working group and an Editor’s Draft in the W3C CSS working group).  We've received positive feedback from other browser vendors (i.e., Mozilla and, to a lesser extent, Microsoft) about the feature’s feasibility and value.


Closing thoughts

Shipping Shadow DOM is a risk.  There’s certainly a chance that other browser implementers will take a different approach to providing web developers composition primitives.  We’ve done our best to mitigate this risk through engaging with the W3C and with the Polymer team, but once we ship Shadow DOM, we’ll doubtedly get more feedback from web developers, which we can use to evolve the feature.  Hopefully Shadow DOM will grow into something web developers love.


Adam



Anne van Kesteren

unread,
Mar 21, 2014, 10:14:49 AM3/21/14
to Adam Barth, Kenji Baheux, blink-dev
On Thu, Mar 20, 2014 at 6:30 PM, Adam Barth <aba...@chromium.org> wrote:
> Mozilla has provided positive feedback about the feature and is currently
> implementing Shadow DOM behind a runtime flag. Based on these discussions,
> Mozilla appears to be on track to ship a compatible implementation at some
> point in the future.

I think http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0438.html
is the latest we said on the subject. We plan to have an experimental
implementation and what we ship is still an open question. Based on
feedback e.g. bz has given I would expect some at Mozilla to be more
behind Apple's position. As far as I can tell Google is the only party
firmly behind the status quo.


--
http://annevankesteren.nl/

Adam Barth

unread,
Mar 21, 2014, 10:23:36 AM3/21/14
to ann...@annevk.nl, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org
Perhaps it's incorrect to say that Mozilla as a whole has provided feedback of one kind or another.  Rather, different folks from Mozilla hold different opinions.  The paragraph above refers to discussions Dimitri Glazkov and others have had with Jonas Sicking after the email you cited.  I'd prefer if those discussions took place in public and I could reference them directly, but hopefully I've characterized them accurately.

Adam

 

Dirk Schulze

unread,
Mar 21, 2014, 12:25:01 PM3/21/14
to Adam Barth, Kenji Baheux, blink-dev

On Mar 20, 2014, at 7:30 PM, Adam Barth <aba...@chromium.org> wrote:

> Closing thoughts
> Shipping Shadow DOM is a risk. There’s certainly a chance that other browser implementers will take a different approach to providing web developers composition primitives. We’ve done our best to mitigate this risk through engaging with the W3C and with the Polymer team, but once we ship Shadow DOM, we’ll doubtedly get more feedback from web developers, which we can use to evolve the feature. Hopefully Shadow DOM will grow into something web developers love.

Should the standards body change the specification and the implementation in Blink is not compatible to the specification anymore, will Blink change the implementation? Even if it potentially breaks existing content? It seems likely that Apple and Mozilla will request certain modifications.

Greetings,
Dirk

Adam Barth

unread,
Mar 21, 2014, 12:28:41 PM3/21/14
to dsch...@chromium.org, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org
On Fri Mar 21 2014 at 9:25:08 AM, Dirk Schulze <dsch...@chromium.org> wrote:
On Mar 20, 2014, at 7:30 PM, Adam Barth <aba...@chromium.org> wrote:

> Closing thoughts
> Shipping Shadow DOM is a risk.  There’s certainly a chance that other browser implementers will take a different approach to providing web developers composition primitives.  We’ve done our best to mitigate this risk through engaging with the W3C and with the Polymer team, but once we ship Shadow DOM, we’ll doubtedly get more feedback from web developers, which we can use to evolve the feature.  Hopefully Shadow DOM will grow into something web developers love.

Should the standards body change the specification and the implementation in Blink is not compatible to the specification anymore, will Blink change the implementation? Even if it potentially breaks existing content?

Our ability to change our implementation of shipped features, including Shadow DOM, is constrained by our desire to remain compatible with content that uses those features.

It seems likely that Apple and Mozilla will request certain modifications.

Hence the risk.

Adam

PhistucK

unread,
Mar 21, 2014, 12:30:37 PM3/21/14
to Adam Barth, Dirk Schulze, Adam Barth, kenji...@chromium.org, blink-dev
After reading the response by Anne that Firefox tends towards the approach (that would be) taken by Apple, I think Blink would wait with shipping this.
The push for shipping this in such a rush makes Google look somewhat draconian, especially given the response by Anne.


PhistucK


Adam Barth

unread,
Mar 21, 2014, 12:39:04 PM3/21/14
to phis...@gmail.com, dsch...@chromium.org, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org
On Fri Mar 21 2014 at 9:31:17 AM, PhistucK <phis...@gmail.com> wrote:
After reading the response by Anne that Firefox tends towards the approach (that would be) taken by Apple, I think Blink would wait with shipping this.
The push for shipping this in such a rush makes Google look somewhat draconian, especially given the response by Anne.

There appear to be some communication issues within the Mozilla organization.  I'm not why why Anne thinks an email from February reflects the current thinking of Mozillians on this topic.

Adam

Erik Bryn

unread,
Mar 21, 2014, 12:51:03 PM3/21/14
to PhistucK, Adam Barth, Dirk Schulze, Adam Barth, kenji...@chromium.org, blink-dev
On Fri, Mar 21, 2014 at 9:30 AM, PhistucK <phis...@gmail.com> wrote:
> After reading the response by Anne that Firefox tends towards the approach
> (that would be) taken by Apple, I think Blink would wait with shipping this.
> The push for shipping this in such a rush makes Google look somewhat
> draconian, especially given the response by Anne.

I agree.

As a framework author that speaks to other library/framework authors
frequently (include some at Google itself), I don't think it's
completely clear right now how today's popular JS libraries/frameworks
will utilize Shadow DOM or some of the other web components API
effectively.

I also find that Polymer being continually referenced as a reason to
ship Shadow DOM quite annoying. From my understanding, Polymer is a
pre-1.0 Google project/experiment intended to test the viability of
the web component specs that Google is promoting. I think we need more
outside influence from other vendors and the community.

I greatly appreciate the work that is being done, but I feel that the
Chrome team is pushing a little too hard.

- Erik

Dimitri Glazkov

unread,
Mar 21, 2014, 12:57:30 PM3/21/14
to Adam Barth, Alon Gothshmidt, Dirk Schulze, Adam Barth, Kenji Baheux, blink-dev
On Fri, Mar 21, 2014 at 9:39 AM, Adam Barth <aba...@google.com> wrote:
On Fri Mar 21 2014 at 9:31:17 AM, PhistucK <phis...@gmail.com> wrote:
After reading the response by Anne that Firefox tends towards the approach (that would be) taken by Apple, I think Blink would wait with shipping this.
The push for shipping this in such a rush makes Google look somewhat draconian, especially given the response by Anne.

There appear to be some communication issues within the Mozilla organization.  I'm not why why Anne thinks an email from February reflects the current thinking of Mozillians on this topic.

A couple of weeks ago, I reached out to Jonas Sicking, and asked him to provide some feedback that I could use to gauge Mozilla's position in regard to Shadow DOM. Quoting here, with his permission:

---
There aren't any obvious issues in the parts that are specced so far.
There are some obvious missing features such as JS API for managing
insertion points, and allowing the :not() selector.

I would also like to see the "type 2 encapsulation" from maciej's
post. But I don't think there's any mozilla consensus on that, so
that's more my opinion.

But we also haven't had the opportunity to test the spec "in the real
world". And so I expect that we will find issues once we do. In
particular around inheritance as that seems like one of the complex
pieces, and also a piece where we have the least experience from XBL1.

So given our lack of testing, and the complexity of the feature, it's
hard to feel super confident. But I think you guys have done a great
work of testing and developing, so I expect a lot fewer issues than I
otherwise would. And I expect more problems on the type of "X is
missing" than "Y is done the wrong way". Which is a great sign.
---

What we're shipping is a minimum viable product, and there's still a lot of work to do here. All items he mentioned are incremental work that is on the plate for this year, both in spec and implementation.

:DG<

Dirk Schulze

unread,
Mar 21, 2014, 1:15:24 PM3/21/14
to Adam Barth, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org
Just to confirm what I understand from this comment:

Blink prioritize compatibility to old, existing content higher than interoperability to other implementations and specification conformance?

Wasn’t the main goal of introducing run time flags and the strict sipping rules to avoid exactly this situation?

Greetings,
Dirk

Adam Barth

unread,
Mar 21, 2014, 1:23:44 PM3/21/14
to dsch...@chromium.org, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org
On Fri Mar 21 2014 at 10:15:28 AM, Dirk Schulze <dsch...@chromium.org> wrote:
On Mar 21, 2014, at 5:28 PM, Adam Barth <aba...@google.com> wrote:

> On Fri Mar 21 2014 at 9:25:08 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> On Mar 20, 2014, at 7:30 PM, Adam Barth <aba...@chromium.org> wrote:
>
> > Closing thoughts
> > Shipping Shadow DOM is a risk.  There’s certainly a chance that other browser implementers will take a different approach to providing web developers composition primitives.  We’ve done our best to mitigate this risk through engaging with the W3C and with the Polymer team, but once we ship Shadow DOM, we’ll doubtedly get more feedback from web developers, which we can use to evolve the feature.  Hopefully Shadow DOM will grow into something web developers love.
>
> Should the standards body change the specification and the implementation in Blink is not compatible to the specification anymore, will Blink change the implementation? Even if it potentially breaks existing content?
>
> Our ability to change our implementation of shipped features, including Shadow DOM, is constrained by our desire to remain compatible with content that uses those features.

Just to confirm what I understand from this comment:

Blink prioritize compatibility to old, existing content higher than interoperability to other implementations and specification conformance?

That's not what I wrote.  Compatibility with existing content is a constraint on improving interoperability with other implementations.  That's not something unique to Blink.  It's true for all browser engines.

Wasn’t the main goal of introducing run time flags and the strict shipping rules to avoid exactly this situation?

The goal of using runtime flags is to decouple the decision about when to ship a feature from the decision about when to implement a feature.

The goal of shipping guidelines is to document the process by which we factor compatibility concerns into our decision about whether or not to ship a feature.

Adam

Dirk Schulze

unread,
Mar 21, 2014, 1:43:22 PM3/21/14
to Adam Barth, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org

On Mar 21, 2014, at 6:23 PM, Adam Barth <aba...@google.com> wrote:

> On Fri Mar 21 2014 at 10:15:28 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> On Mar 21, 2014, at 5:28 PM, Adam Barth <aba...@google.com> wrote:
>
> > On Fri Mar 21 2014 at 9:25:08 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> > On Mar 20, 2014, at 7:30 PM, Adam Barth <aba...@chromium.org> wrote:
> >
> > > Closing thoughts
> > > Shipping Shadow DOM is a risk. There’s certainly a chance that other browser implementers will take a different approach to providing web developers composition primitives. We’ve done our best to mitigate this risk through engaging with the W3C and with the Polymer team, but once we ship Shadow DOM, we’ll doubtedly get more feedback from web developers, which we can use to evolve the feature. Hopefully Shadow DOM will grow into something web developers love.
> >
> > Should the standards body change the specification and the implementation in Blink is not compatible to the specification anymore, will Blink change the implementation? Even if it potentially breaks existing content?
> >
> > Our ability to change our implementation of shipped features, including Shadow DOM, is constrained by our desire to remain compatible with content that uses those features.
>
> Just to confirm what I understand from this comment:
>
> Blink prioritize compatibility to old, existing content higher than interoperability to other implementations and specification conformance?
>
> That's not what I wrote. Compatibility with existing content is a constraint on improving interoperability with other implementations. That's not something unique to Blink. It's true for all browser engines.

You are right up to a certain point. WebKit and IE ship prefixed, allowing to make the final implementation interoperable and spec compliant. Firefox just ships if there is a general agreement across browser vendors and implementations that proof interoperability (flagged features count).

What you suggest is shipping unprefixed, not having consensus with other vendors, not having interoperable second browser implementations and at the same time don’t adapt the implementation if it is not compatible to other future browser implementations and specification changes. You might not have said my interpretation of your response but practically it is exactly what it means.

Greetings,
Dirk

Adam Barth

unread,
Mar 21, 2014, 1:54:52 PM3/21/14
to dsch...@chromium.org, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org
On Fri Mar 21 2014 at 10:43:26 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Mar 21, 2014, at 6:23 PM, Adam Barth <aba...@google.com> wrote:

> On Fri Mar 21 2014 at 10:15:28 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> On Mar 21, 2014, at 5:28 PM, Adam Barth <aba...@google.com> wrote:
>
> > On Fri Mar 21 2014 at 9:25:08 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> > On Mar 20, 2014, at 7:30 PM, Adam Barth <aba...@chromium.org> wrote:
> >
> > > Closing thoughts
> > > Shipping Shadow DOM is a risk.  There’s certainly a chance that other browser implementers will take a different approach to providing web developers composition primitives.  We’ve done our best to mitigate this risk through engaging with the W3C and with the Polymer team, but once we ship Shadow DOM, we’ll doubtedly get more feedback from web developers, which we can use to evolve the feature.  Hopefully Shadow DOM will grow into something web developers love.
> >
> > Should the standards body change the specification and the implementation in Blink is not compatible to the specification anymore, will Blink change the implementation? Even if it potentially breaks existing content?
> >
> > Our ability to change our implementation of shipped features, including Shadow DOM, is constrained by our desire to remain compatible with content that uses those features.
>
> Just to confirm what I understand from this comment:
>
> Blink prioritize compatibility to old, existing content higher than interoperability to other implementations and specification conformance?
>
> That's not what I wrote.  Compatibility with existing content is a constraint on improving interoperability with other implementations.  That's not something unique to Blink.  It's true for all browser engines.

You are right up to a certain point. WebKit and IE ship prefixed, allowing to make the final implementation interoperable and spec compliant. Firefox just ships if there is a general agreement across browser vendors and implementations that proof interoperability (flagged features count).

What you suggest is shipping unprefixed, not having consensus with other vendors, not having interoperable second browser implementations and at the same time don’t adapt the implementation if it is not compatible to other future browser implementations and specification changes. You might not have said my interpretation of your response but practically it is exactly what it means.

Perhaps we should take this discussion to a different thread?  We're not talking about shipping guidelines in general rather than about Shadow DOM specifically.

We've had the same shipping guidelines since we launched the Blink project almost a year ago.  In writing those guidelines, we strove to balance various factors and find an approach that's better for the web at large than vendor prefixes.  I'm certain we haven't found the best balance, and we're likely to evolve the guidelines over time, as the guidelines themselves say.

I think it's an encouraging sign that Mozilla has adopted similar guidelines:


One thing I like about their guidelines is a unifying question of "is this good for the Web?"  Next time we revise Blink's guidelines, I'll probably advocate for something similar.

You're right that some of this business is like making sausage.  We've decided to make our sausage in public so that folks like yourself can participate and share our hopes and fears.  I also agree with you that there's a risk that we might come to regret this decision.  However, we think it's the right thing to do at this point, for the reasons I wrote originally.

Adam

Dirk Schulze

unread,
Mar 21, 2014, 2:03:45 PM3/21/14
to Adam Barth, aba...@chromium.org, kenji...@chromium.org, blin...@chromium.org

On Mar 21, 2014, at 6:54 PM, Adam Barth <aba...@google.com> wrote:

> On Fri Mar 21 2014 at 10:43:26 AM, Dirk Schulze <dsch...@chromium.org> wrote:
>
> On Mar 21, 2014, at 6:23 PM, Adam Barth <aba...@google.com> wrote:
>
> > On Fri Mar 21 2014 at 10:15:28 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> > On Mar 21, 2014, at 5:28 PM, Adam Barth <aba...@google.com> wrote:
> >
> > > On Fri Mar 21 2014 at 9:25:08 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> > > On Mar 20, 2014, at 7:30 PM, Adam Barth <aba...@chromium.org> wrote:
> > >
> > > > Closing thoughts
> > > > Shipping Shadow DOM is a risk. There’s certainly a chance that other browser implementers will take a different approach to providing web developers composition primitives. We’ve done our best to mitigate this risk through engaging with the W3C and with the Polymer team, but once we ship Shadow DOM, we’ll doubtedly get more feedback from web developers, which we can use to evolve the feature. Hopefully Shadow DOM will grow into something web developers love.
> > >
> > > Should the standards body change the specification and the implementation in Blink is not compatible to the specification anymore, will Blink change the implementation? Even if it potentially breaks existing content?
> > >
> > > Our ability to change our implementation of shipped features, including Shadow DOM, is constrained by our desire to remain compatible with content that uses those features.
> >
> > Just to confirm what I understand from this comment:
> >
> > Blink prioritize compatibility to old, existing content higher than interoperability to other implementations and specification conformance?
> >
> > That's not what I wrote. Compatibility with existing content is a constraint on improving interoperability with other implementations. That's not something unique to Blink. It's true for all browser engines.
>
> You are right up to a certain point. WebKit and IE ship prefixed, allowing to make the final implementation interoperable and spec compliant. Firefox just ships if there is a general agreement across browser vendors and implementations that proof interoperability (flagged features count).
>
> What you suggest is shipping unprefixed, not having consensus with other vendors, not having interoperable second browser implementations and at the same time don’t adapt the implementation if it is not compatible to other future browser implementations and specification changes. You might not have said my interpretation of your response but practically it is exactly what it means.
>
> Perhaps we should take this discussion to a different thread? We're not talking about shipping guidelines in general rather than about Shadow DOM specifically.
>
> We've had the same shipping guidelines since we launched the Blink project almost a year ago. In writing those guidelines, we strove to balance various factors and find an approach that's better for the web at large than vendor prefixes. I'm certain we haven't found the best balance, and we're likely to evolve the guidelines over time, as the guidelines themselves say.
>
> I think it's an encouraging sign that Mozilla has adopted similar guidelines:
>
> https://wiki.mozilla.org/WebAPI/ExposureGuidelines

No, it does not! Interoperability is the most important part of Mozilla’s guideline. The opposite seems to be the case for Shadow DOM in Blink.

>
> One thing I like about their guidelines is a unifying question of "is this good for the Web?" Next time we revise Blink's guidelines, I'll probably advocate for something similar.
>
> You're right that some of this business is like making sausage. We've decided to make our sausage in public so that folks like yourself can participate and share our hopes and fears. I also agree with you that there's a risk that we might come to regret this decision. However, we think it's the right thing to do at this point, for the reasons I wrote originally.

I hope it does not come to it. Shadow DOM is a very interesting concept and it would be a shame that lack of interoperability makes it hard to use it.

Greetings,
Dirk


>
> Adam
>

Elliott Sprehn

unread,
Mar 21, 2014, 2:13:26 PM3/21/14
to Dirk Schulze, Adam Barth, Adam Barth, Kenji Baheux, blink-dev



On Fri, Mar 21, 2014 at 10:43 AM, Dirk Schulze <dsch...@chromium.org> wrote:
[...]

> On Mar 21, 2014, at 5:28 PM, Adam Barth <aba...@google.com> wrote:
>
> [...]

>
> That's not what I wrote.  Compatibility with existing content is a constraint on improving interoperability with other implementations.  That's not something unique to Blink.  It's true for all browser engines.

You are right up to a certain point. WebKit and IE ship prefixed, allowing to make the final implementation interoperable and spec compliant. Firefox just ships if there is a general agreement across browser vendors and implementations that proof interoperability (flagged features count).

Shipping with a prefix doesn't allow you change your final implementation. In practice developers write code like:

AudioContext = window.AudioContext || window.webkitAudioContext;

or 

matches = e.matchesSelector || e.mozMatchesSelector || e.webkitMatchesSelector || e.oMatchesSelector || e.msMatchesSelector;


So changing a prefixed API is just as difficult as changing an unprefixed one as you're just as likely to break existing content. The thing that matters when making breaking changes is the UseCounter for your feature.


What you suggest is shipping unprefixed, not having consensus with other vendors, not having interoperable second browser implementations and at the same time don’t adapt the implementation if it is not compatible to other future browser implementations and specification changes. [...]

We're certainly interested in making Blink compatible with other engines, but we're unlikely to make breaking changes to a feature (prefixed or otherwise) that's used by lots of content.

- E 

Dirk Schulze

unread,
Mar 21, 2014, 2:50:08 PM3/21/14
to Elliott Sprehn, Adam Barth, Adam Barth, Kenji Baheux, blink-dev

On Mar 21, 2014, at 7:13 PM, Elliott Sprehn <esp...@chromium.org> wrote:

>
>
>
> On Fri, Mar 21, 2014 at 10:43 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> [...]
> > On Mar 21, 2014, at 5:28 PM, Adam Barth <aba...@google.com> wrote:
> >
> > [...]
> >
> > That's not what I wrote. Compatibility with existing content is a constraint on improving interoperability with other implementations. That's not something unique to Blink. It's true for all browser engines.
>
> You are right up to a certain point. WebKit and IE ship prefixed, allowing to make the final implementation interoperable and spec compliant. Firefox just ships if there is a general agreement across browser vendors and implementations that proof interoperability (flagged features count).
>
> Shipping with a prefix doesn't allow you change your final implementation. In practice developers write code like:
>
> AudioContext = window.AudioContext || window.webkitAudioContext;
>
> or
>
> matches = e.matchesSelector || e.mozMatchesSelector || e.webkitMatchesSelector || e.oMatchesSelector || e.msMatchesSelector;
>
> ex. http://www.html5rocks.com/en/tutorials/webaudio/intro/ and http://jsperf.com/mozmatchesselector/11
>
> So changing a prefixed API is just as difficult as changing an unprefixed one as you're just as likely to break existing content. The thing that matters when making breaking changes is the UseCounter for your feature.

That is a very interesting argumentation. Especially because Eric arguments agains changing behavior of prefixed properties for backward compatibility reasons and instead implement it correctly for the unprefixed version of the property. See discussion "[blink-dev] Fixing Prefixed (-webkit-) Features”.

Greetings,
Dirk

Boris Zbarsky

unread,
Mar 21, 2014, 4:59:33 PM3/21/14
to blink-dev
On 3/20/14 2:30 PM, Adam Barth wrote:
> Based on these discussions, Mozilla appears to
> be on track to ship a compatible implementation at some point in
> the future.

We are not aware of anyone within Mozilla who feels this statement
accurately reflects our position. Certainly the people who are working
on the Shadow DOM implementation do not feel that it does.

What we have been consistently saying is that the feature set here is
large and has widespread effects on the platform. While we don't see any
immediate big flaws, we can't express confidence in the spec until we
have gotten it tested by authors. So our current plan is to do an
implementation "behind a flag" and then get author feedback.

We definitely think there is a risk that this author feedback will
require incompatible changes to the spec.

We are aware of at least one issue
(<https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887>) where the only
person at Mozilla who has looked at it disagrees with the current spec
and is actively discussing this in the bug. So there seems to be
significant risk of changes there.

Furthermore, we have not had a chance to review the latest set of
(large) changes/updates to the styling parts of the spec which happened
just a few days ago. So we cannot comment on them usefully at this time
or in any way commit to implementing them compatibly with what Blink has
right now.

We do think that the authors of the spec have done a great job, and we
hope that the above loose ends can be found and tied up soon, and that
author feedback will be positive.

William Chen
Jonas Sicking
Boris Zbarsky

Ojan Vafai

unread,
Mar 23, 2014, 8:01:13 PM3/23/14
to Dirk Schulze, Elliott Sprehn, Adam Barth, Adam Barth, Kenji Baheux, blink-dev
On Fri, Mar 21, 2014 at 11:50 AM, Dirk Schulze <dsch...@chromium.org> wrote:
On Mar 21, 2014, at 7:13 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> On Fri, Mar 21, 2014 at 10:43 AM, Dirk Schulze <dsch...@chromium.org> wrote:
> > On Mar 21, 2014, at 5:28 PM, Adam Barth <aba...@google.com> wrote:
> > That's not what I wrote.  Compatibility with existing content is a constraint on improving interoperability with other implementations.  That's not something unique to Blink.  It's true for all browser engines.
>
> You are right up to a certain point. WebKit and IE ship prefixed, allowing to make the final implementation interoperable and spec compliant. Firefox just ships if there is a general agreement across browser vendors and implementations that proof interoperability (flagged features count).
>
> Shipping with a prefix doesn't allow you change your final implementation. In practice developers write code like:
>
> AudioContext = window.AudioContext || window.webkitAudioContext;
>
> or
>
> matches = e.matchesSelector || e.mozMatchesSelector || e.webkitMatchesSelector || e.oMatchesSelector || e.msMatchesSelector;
>
> ex. http://www.html5rocks.com/en/tutorials/webaudio/intro/ and http://jsperf.com/mozmatchesselector/11
>
> So changing a prefixed API is just as difficult as changing an unprefixed one as you're just as likely to break existing content. The thing that matters when making breaking changes is the UseCounter for your feature.

That is a very interesting argumentation. Especially because Eric arguments agains changing behavior of prefixed properties for backward compatibility reasons and instead implement it correctly for the unprefixed version of the property. See discussion "[blink-dev] Fixing Prefixed (-webkit-) Features”.

For what it's worth, there's isn't a clear consensus on that in the Blink community. For the reason Elliott mentions and because of increased implementation complexity, I don't support Eric's plan to not touch the behavior of prefixed APIs as we implement the unprefixed ones. In practice, I don't think we'll be able to get away with it. I think that, to the extent possible, we should try to keep the prefixed and unprefixed APIs the same. So far we have very little experience with these sorts of things though.

Rune Lillesveen

unread,
Mar 24, 2014, 8:11:14 AM3/24/14
to kenji...@google.com, blink-dev, Tab Atkins Jr.
On Mon, Mar 10, 2014 at 8:31 AM, <kenji...@google.com> wrote:
> There was one more round of discussion about the alternative to Cat ^ and
> Hat ^^ which delayed the implementation change.
> The CL to rename ^ and ^^ selectors in accordance with the spec's /shadow/
> and /shadow-deep/ is still under review but is being hold on for an
> unrelated nit.
> We are confident that the CL will land shortly.
>
>
> Therefore, I would like to resume the intent to ship Shadow DOM.

I don't know how much of a moving target this is (added Tab), but
recently selectors were renamed again [1]:

:ancestor() -> :host-context()
/shadow-deep/ -> /deep/
/shadow/ -> ::shadow

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

--
Rune Lillesveen

Tab Atkins Jr.

unread,
Mar 24, 2014, 1:44:01 PM3/24/14
to Rune Lillesveen, Kenji Baheux, blink-dev
I've been shuffling syntax in order to get fantasai into accord with
the spec - all of the recent changes were the result of a conversation
between me, fantasai, and Dimitri, where fantasai explained her
position favoring pseudo-elements more eloquently, and Dimitri gave
some more nuanced perspective on our implementation concerns
(specifically, that they weren't as strong as I'd been led to
believe), so we were able to shift more in her favored direction.
This appears to also be the direction several in the CSSWG favored, so
hopefully this is a change toward greater harmony.

I've also been making bugfixes to cascading/etc as they're pointed out to me.

Naming changes are a little bit confusing in the middle of a
conversation, I agree, but they're not anything that should slow or
stop evaluation of the spec.

~TJ

Rune Lillesveen

unread,
Mar 24, 2014, 2:00:20 PM3/24/14
to Tab Atkins Jr., Kenji Baheux, blink-dev
I have no issues with the renaming. The reason I brought it up in this
thread was in the context of shipping. If we're shipping, should we do
the renaming in the implementation according to the latest draft asap?

--
Rune Lillesveen

Tab Atkins Jr.

unread,
Mar 24, 2014, 5:52:52 PM3/24/14
to Rune Lillesveen, Kenji Baheux, blink-dev
Yes, the renames will happen before shipping. They're super-fast to
do, so that's not a concern.

~TJ
Reply all
Reply to author
Forward
0 new messages