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: Erik Arvidsson <arv@chromium.org>
Date: Fri, 6 Dec 2013 10:05:17 -0500
Message-ID: <CAJ8+GogK9sE1ZF+RG8zDrQz85BJcePToH+6aPyBgXsLf7aJhbQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Ryosuke Niwa <rniwa@apple.com>, public-webapps <public-webapps@w3.org>
The custom element draft does add a new synchronization point. After
setting innerHTML (for example), before returning to the script the
callbacks for the custom elements created by innerHTML are called in tree
order.

This does lead to the possibility to observer objects that have not yet had
their created callback been called yet. I think this trade off is
inevitable, no matter whether we use @@create, constructor or created. I
just don't see us being able to call user code every time a node is created.




On Fri, Dec 6, 2013 at 1:58 AM, Boris Zbarsky <bzbarsky@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.
>
> 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
>
>


-- 
erik
Received on Friday, 6 December 2013 15:06:05 UTC

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