[components] Apple's consolidated feedback on Web Components

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.