Apple's updated feedback on Custom Elements and Shadow DOM
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:[email protected]]
- 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).
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:[email protected]]
- 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.)
From: Maciej Stachowiak [mailto:[email protected]]
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 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.
Want more features?
Request early access to our private beta of readable email premium.
- Go to Source
# Maciej Stachowiak (8 months ago)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 ====
II. ==== Shadow DOM ====