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

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

        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. 

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

        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 
                2. We think inserted/removed callbacks should be added, for 
alignment with DOM. <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. 

        C. Upgrade
                1. We don’t think upgrading should be supported. The tradeoffs 
of different options have been much-discussed. 
                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. 

        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. 

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

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

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

Reply via email to