W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2013

Re: Why can't we just use constructor instead of createdCallback?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 06 Dec 2013 01:58:39 -0500
Message-ID: <52A1759F.5080507@mit.edu>
To: Ryosuke Niwa <rniwa@apple.com>
CC: public-webapps@w3.org
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.

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.

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.

All that still seems more palatable than trying to completely revise 
HTML parsing to be robust to constructors running when the element is 
created....

Might be worth checking on public-script-coord to see what the TC39 
folks think about all this.

-Boris
Received on Friday, 6 December 2013 06:59:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:20 UTC