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 <jo...@sicking.cc> wrote: > On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky <bzbar...@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
