I’m re-sending the following message from Maciej because I received a
report that some members of the list didn’t receive it when he sent it

However, note that it did reach the list, because it’s already archived at

----- Forwarded message from Maciej Stachowiak <m...@apple.com> -----

From: Maciej Stachowiak <m...@apple.com>
Date: Mon, 20 Jul 2015 18:17:24 -0700
To: public-webapps <public-webapps@w3.org>
Subject: Apple's updated feedback on Custom Elements and Shadow DOM

A while back we sent a consolidated pile of feedback on the Web Components 
family of specs. In preparation for tomorrow's F2F, here is an update on our 
positions. We've also changed the bugzilla links to point to relevant github 
issues instead.

We're only covering Custom Elements (the main expected topic), and also Shadow 
DOM (in case that gets discussed too).

I. ==== Custom Elements ====

        A. ES6 classes / Upgrade / Synchronous Constructors
                1. In general, we support the "synchronous constructors" 
approach to the "prototype swizzling" approach, as the lesser evil. While 
tricky to implement correctly, it makes a lot more sense and fits more 
naturally into the language. We are willing to do the work to make it feasible.
                2. Custom elements should support initialization using an ES6 
class constructo instead of a separate callback. 
                3. We don’t think upgrading should be supported. The tradeoffs 
of different options have been much-discussed. 
                4. Specifically, we don't really like the "Optional Upgrades, 
Optional Constructors" proposal (seems like it's the worst of both worlds in 
terms of complexity and weirdness) or the "Parser-Created Classes" proposal 
(not clear how this even solves the problem).

        B. 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. The primitives should be insertedIntoDocument / removedFromDocument 
and inserted / removed. If you care about whether your document is rendered, 
look at its defaultView property. 
                2. We think inserted/removed callbacks should be added, for 
alignment with DOM. <https://github.com/w3c/webcomponents/issues/222>

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

        D. 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://github.com/w3c/webcomponents/issues/136>

        E. Renaming the API
                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. This will almost certainly be true if we switch from 
createdCallback to constructors as the initializers.

II. ==== Shadow DOM ====

        A. Closed vs. Open.
                1. A closed/open flag has been added to createShadowRoot(). It 
seems this has been done. We are ok with the syntax. 
                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 wanted closed mode to be the default but we are ok with 
having no default, as was decided at the last F2F.

        B. Multiple Generations of Shadow DOM
                1. We are glad to see that multiple generations of Shadow DOM 
has been removed per F2F agreement.
                2. After further consideration, we are even more convinced that 
the "named slot" proposal is the way to go for distribution for v1. Original 
proposal here: 
 Some detailed algorithms written out here: 
 Github issue here: <https://github.com/w3c/webcomponents/issues/138>

        C. Imperative Distribution API
                1. We think the imperative distribution API may be worth doing, 
but we're no longer confident that it is important for v1. 

        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). It seems like the issue is marked for v2, but we 
thought we'd all agreed to do something here for v1? 

        E. Renaming the API
                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. We are not sure if this will be 
required, but named slots may force it if adopted.

----- End forwarded message -----

Michael[tm] Smith https://people.w3.org/mike

Attachment: signature.asc
Description: Digital signature

Reply via email to