- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 13 Feb 2014 18:50:39 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>, Dimitri Glazkov <dglazkov@google.com>
- 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>
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 02:51:37 UTC