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
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?
Link to entry on the feature dashboard
http://www.chromestatus.com/features/4507242028072960
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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 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
[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<
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.
Out of curiosity, do you know of any JS frameworks other than Polymer that rely on Web Components?
- Erik
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.
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.
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-domSummary
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
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.
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.
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.
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?
Wasn’t the main goal of introducing run time flags and the strict shipping rules to avoid exactly this situation?
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.
> [...]
>
> 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. [...]
On Mar 21, 2014, at 7:13 PM, Elliott Sprehn <esp...@chromium.org> wrote: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”.
> 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.