W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 22 Jan 2014 17:21:34 -0800
Message-ID: <CA+c2ei-LL5=Dim027046jm9W2h+aGVeTdU7H-PHHt+g9o0AFtw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Ryosuke Niwa <rniwa@apple.com>, Erik Arvidsson <arv@chromium.org>, WebApps WG <public-webapps@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, William Chen <wchen@mozilla.com>
On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> One idea that came out of our discussion is was to add an additional step
>> in the parser to call constructors on all “pending” elements before they’re
>> being constructed into the DOM tree.
>
> Isn't that the bad thing we _don't_ want to do?  That is, invoke arbitrary
> page JS from the middle of the parsing algorithm?

The idea was to do something like this:

1. While parsing, when you hit a custom element (with a constructor)
don't insert that element into its parent, nor insert any of its
children into the element.
2. Put each such element into an array along with meta-info about what
parent and children it should have.
3. Once you're done parsing as much as you want to parse (i.e. until
you hit a network boundary or feel the need to return to the event
loop), unwind enough of the calling stack until you feel comfortable
running content JS.
4. Run the constructor for the first element in the array.
5. After a constructor has been run, insert the element into its
parent, and insert its children into the element.
6. Remove the element from the array and, unless the array is empty,
go back to step 4.

This is somewhat simplified. You also have to make sure not to insert
an elements into a parent where previous siblings are still pending to
be inserted.

The big question of course is if tracking the elements in the separate
array and inserting them after their constructor has run will be a
performance issue.

In Gecko it might be a bit of a problem since we can get O(n^2)
performance issues where n is the nesting depth of custom elements.
This is due to our recursive BindToTree notification which cause
problems when trees are constructed "bottom up"

But possibly this can be solved. And possibly other implementations
doesn't have the same problem. Or possibly they have worse problems.

But it wasn't immediately obvious to me that this wouldn't work.

/ Jonas
Received on Thursday, 23 January 2014 01:22:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:08 UTC