Hi everyone,
In preparation for Fridays’ face-to-face, a number of us at Apple (including
me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor) got together to collect our
thoughts and feedback about the current state of Web Components.
Before going into the changes we propose, we want to reiterate that we think
the concept of Web Components is great, and we even like many of the specifics.
We’re considering significant implementation effort, but we have some concerns.
We think there is a set of targeted changes that would help web developers, and
allow us to address a broader set of use cases.
With that in mind, here are our key points of feedback, by spec.
I. ==== Shadow DOM ====
A. Closed vs. Open.
1. Add a closed/open flag to createShadowRoot(). The Shadow DOM
spec now has the notion of an encapsulation flag for closed mode. Yay!
Unfortunately, there’s no way yet for a Web developer to pass this flag in.
Open vs. closed has been much discussed, and while the default is contentious,
we felt there was a rough consensus to at least expose both modes. We think
this is critical for v1. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144>>
2. The behavior of closed mode should be actually defined. We
hope this does not need much justification. We think this is critical for v1.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144>>
3. We think closed mode should be the default. Alternately, we
would be ok with a mandatory argument so developers must always explicitly
choose open or closed. This has been much discussed, so we won’t give further
rationale here, and can wait for the meeting Friday to debate.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28445
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28445>>
B. Multiple Generations of Shadow DOM
1. We think this should be removed. Discussion can wait for
debate of "contentious bits", <https://www.w3.org/Bugs/Public/show_bug.cgi?
<https://www.w3.org/Bugs/Public/show_bug.cgi?>id=28446>
2. We think that the Apple / Component Kitchen "named slot"
proposal does a better job of addressing the main use cases for this. We think
it is a superior replacement.
<https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
<https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution>>
<https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0184.html
<https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0184.html>>
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28542
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28542>>
C. Imperative Distribution API
1. We think the imperative distribution API is still worth
doing. There has been positive feedback from web developers on the concept and
there isn’t an obvious reason against it.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429>>
D. Event Retargeting
1. We agree with making it optional (opt-in or opt-out). We
don’t feel that strongly, but many web developers have asked for this. The
default should likely match the default for open vs. closed (no retargeting by
default if open by default).
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444>>
E. Renaming
1. If any strongly incompatible changes are made, we suggest
renaming createShadowRoot. This is to avoid compat problems with content
written for Chrome’s shipping implementation.
II. ==== Custom Elements ====
A. Insertion/Removal Callbacks
1. We think the current attached/detached callbacks should be
removed. They don’t match core DOM concepts and insert/remove is a more natural
bracket. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314>>
2. We think inserted/removed callbacks should be added, for
alignment with DOM. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866>>
B. ES6 classes
1. Custom elements should support ES6 classes in a natural way
- allowing use of the ES6 class constructor instead of a separate callback. We
believe there is rough consensus on this point.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28541
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28541>>
C. Upgrade
1. We don’t think upgrading should be supported. The tradeoffs
of different options have been much-discussed.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544>>
2. We support synchronous constructors, or Jonas’s
almost-synchronous constructors alternative. There are tradeoffs, but we
believe that on the whole this is the least complex.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28543
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28543>>
<https://lists.w3.org/Archives/Public/public-
<https://lists.w3.org/Archives/Public/public->webapps/2014JanMar/0098.html>
D. Inheritance for Built-ins
1. We think support for inheritance from built-in elements
(other than HTMLElement/SVGElement) should be omitted from a cross-browser v1.
It raises complex implementation issues.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28547
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28547>>
E. Syntactic Sugar / Developer Ergonomics
1. We think it would be useful (perhaps post-v1) to make it
simpler to create a custom element that is always instantiated with a shadow
DOM from a template. Right now, this common use case requires script and a
template in separate places, and a few lines of confusing boilerplate code.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546>>
2. We think at some point (perhaps post-V1), there should be a
convenient declarative syntax that combines script and a template to define a
custom element. JavaScript frameworks on top of web components provide
something like this. Perhaps with field experience we can make a standardized
common syntax. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=28545
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28545>>
F. Renaming
1. We’re still not wholly sold on document.registerElement as a
name. We like document.define or document.defineElement. At minimum, we’d like
the WG to decide on the name instead of just leaving it at the editor’s initial
decision. We can probably live with this not changing though.
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24087
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24087>>
2. If anything about Custom Elements is changed incompatibly,
we suggest renaming document.registerElement (whether to one of our suggestions
or another). This is to avoid compat problems with content written for Chrome’s
shipping implementation.
III. ==== Styling & CSS ====
A. Shadow-Piercing Combinators
1. At minimum, they need to be specified to respect closed
mode. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25330
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25330>>
2. It may be a good idea to remove them entirely. Custom
pseudo-elements are a better solution to the problem, and won’t create
accidental API contracts on the structure of a custom element's shadow DOM.
Pros/cons for this are discussed in the contentious bits document at
<https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits
<https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits>>.
B. Custom Pseudos / Named Parts
3. We think there should be a way to expose selected parts of
the shadow DOM (with whitelist of allowed CSS properties) as named parts that
can be addressed in CSS. This allows components to have style customization
without requiring their clients to code in dependencies on details of their DM
structure. <https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html
<https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html>>
IV. ==== HTML Templates ====
A. Data Binding
1. We think templates should be expanded with data binding.
This doesn’t necessarily gate v1 of other Web Components specs. We haven’t
filed a bug yet because we’re not sure where the best place to file it would
be. We don’t think this is contentious.
V. ==== HTML Imports ====
A. Isolated Imports
1. We think a DOM- and script-isolated imports, in combination
with custom elements and closed shadow DOM, can be used to build fully two-way
isolated components. Specifically:
2. There should be a form of import syntax that can work
cross-origin, and which gives a separate global object and document.
3. Provide a way to selectively import custom element
definition from an isolated import.
4. Provide a two-way membrane around all interfaces into and
out of the custom element. It can use the structured clone algorithm, expanded
to also cover DOM objects (translating their identities between different
global objects).
5. We will send a more detailed outline of this proposal
shortly.
6. This doesn’t necessarily need to gate the other specs, but
we think this direction is an important part of the rationale for closed shadow
DOM.
