On Dec 5, 2013, at 10:58 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 12/6/13 1:49 AM, Ryosuke Niwa wrote: >> Then how do we define a custom element using ES6 classes? Are we going to >> not call the constructor? > > An excellent question, indeed. I don't have a good answer for you.
It appears to me that we should definitely have a good answer for this question before the specification reaches CR given that the definition of ES6 classes is pretty stable at this point. > If we do make elements subclassable (which it seems like we should), we would > presumably need to make the actual default constructor of the built-in > element classes a no-op, since we can't actually rely on the subclass calling > it. All the relevant setup would need to be done by @@create. > > Given that, we could maybe cheat and in fact do some sort of delayed calling > of the constructor of ES6 subclasses of elements. You'd still be able to > observe these objects in an "unconstructed" state from the subclass pov, but > at least it wouldn't be a security issue in terms of operating on a DOM > that's in an inconsistent state from the point of view of privileged code. Right. I know it sounds so cheesy but I was suggesting something along that line. > It's not clear to me how OK such an "unconstructed" state is. I suppose it's > no worse than someone extending the ES6 subclass in question and then never > calling its constructor... But that's a programming error on the someone's > part, typically, while here we would be effectively forcing this sort of > thing on all Element subclasses. I think the question is how observable such a delay is and what implications it would have. > All that still seems more palatable than trying to completely revise HTML > parsing to be robust to constructors running when the element is created…. Indeed. > Might be worth checking on public-script-coord to see what the TC39 folks > think about all this. Sounds like a good idea. - R. Niwa
