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

We (Apple) support this proposal assuming that we can implement the proposed algorithm efficiently.

We would try to prototype it in WebKit in the coming months and will report implementation issues, including the feasibility of efficient implementation, if exists.

- R. Niwa

On Feb 13, 2014, at 6:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Dimitri, I'd still love to hear feedback from you on the idea above.
> Seems like it could fix one of the design issues that a lot of people
> have reacted to.
> 
> / Jonas
> 
> On Wed, Jan 22, 2014 at 5:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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 Friday, 14 February 2014 03:29:24 UTC