RE: Apple's updated feedback on Custom Elements and Shadow DOM

[Domenic Denicola]

From: Maciej Stachowiak [mailto:m...@apple.com] 

 Does that sound right to you?

 If so, it is not much more appealing than prototype swizzling to us, since 
 our biggest concern is allowing natural use of ES6 classes.

Got it, thanks. So it really does sound like it comes down to

class XFoo extends HTMLElement {
  constructor() {
super();
// init code here
  }
}

vs.

class XFoo extends HTMLElement {
  [Element.created]() {
// init code here
  }
}

which I guess we covered in the past at 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0283.html as 
being a general instance of the inversion of control design pattern, which I 
still don't really understand Apple's objection to. I suppose we can leave that 
for tomorrow.

RE: Apple's updated feedback on Custom Elements and Shadow DOM

[Domenic Denicola]

Thanks very much for your feedback Maciej! I know we'll be talking a lot more 
tomorrow, but one point in particular confused me:

From: Maciej Stachowiak [mailto:m...@apple.com] 

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

Specifically with regard to the latter, what is unclear about how it solves the 
problem? It completely gets rid of upgrades, which I thought you would be in 
favor of.

The former is, as you noted, a compromise solution, that brings in the best of 
both worlds (from some perspectives) and the worst of them (from others).

Re: Apple's updated feedback on Custom Elements and Shadow DOM

[Maciej Stachowiak]

 On Jul 20, 2015, at 10:29 PM, Domenic Denicola d...@domenic.me wrote:
 
 Thanks very much for your feedback Maciej! I know we'll be talking a lot more 
 tomorrow, but one point in particular confused me:
 
 From: Maciej Stachowiak [mailto:m...@apple.com] 
 
 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).
 
 Specifically with regard to the latter, what is unclear about how it solves 
 the problem? It completely gets rid of upgrades, which I thought you would be 
 in favor of.
 
 The former is, as you noted, a compromise solution, that brings in the best 
 of both worlds (from some perspectives) and the worst of them (from others).


Sorry that this was unclear.

From our (many Apple folks') perspective, the biggest problem with the 
prototype swizzling solution is that it doesn't allow natural use of ES6 
classes, in particular with initialization happening through the constructor. 
It seems like parser-created classes do not solve that problem, since 
initialization happens before the class is even defined. It also does not solve 
the secondary problem of FOUC, or the related flash of non-interactive content. 
It *does* seem to solve the secondary problem of modifying prototype chains 
after the fact and in some sense changing the class identity of elements. 

By my best understanding of the anti synchronous constructors position, I 
think there are two key concerns - the need to run arbitrary user code at 
possibly inconvenient moments of parsing or cloning; and the fact that elements 
can't be upgraded to a fancier version after the fact if they are parsed before 
a relevant library loads. It does seem to solve both those problems.

Does that sound right to you?

If so, it is not much more appealing than prototype swizzling to us, since 
our biggest concern is allowing natural use of ES6 classes.


Regards,
Maciej

(The we in this case includes at least myself, Ryosuke Niwa, Sam Weinig, and 
Gavin Barraclough who composed this position statement today; but others at 
Apple have also expressed similar vies in the past.)