Re: [components] Apple's consolidated feedback on Web Components

[Dimitri Glazkov]

Thank you for writing this up, Maciej. Looking forward to the F2F.

:DG<

On Wed, Apr 22, 2015 at 11:19 PM, Maciej Stachowiak  wrote:

>
> > On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak  wrote:
> >
> >
> > 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
>
> I forgot to mention that Gavin Barraclough also contributed to this
> discussion. We also incorporated past feedback from others on the team.
>
>  - Maciej
>

Re: [components] Apple's consolidated feedback on Web Components

[Maciej Stachowiak]

> On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak  wrote:
> 
> 
> 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

I forgot to mention that Gavin Barraclough also contributed to this discussion. 
We also incorporated past feedback from others on the team.

 - Maciej

[components] Apple's consolidated feedback on Web Components

[Maciej Stachowiak]

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

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

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