- From: Erik Arvidsson <arv@chromium.org>
- Date: Fri, 14 Feb 2014 14:03:17 -0500
- To: Dimitri Glazkov <dglazkov@google.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, Ryosuke Niwa <rniwa@apple.com>, WebApps WG <public-webapps@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, William Chen <wchen@mozilla.com>
- Message-ID: <CAJ8+Goigb-rO3knT5WpskHe4OBprnFJfwYkk1RjE9k9c+q2rWg@mail.gmail.com>
Another alternative is to disallow DOM traversal and DOM mutation inside these constructors. By disallow I mean throw an error! Here is a rough outline of what the algorithm might look like. Let there be a global counter CostomElementConstructionCounter which is initially set to 0. 1. Parse and build the DOM tree as usual. Keep track of all custom elements we encounter. 2. At some later point, before any script is run: 3. For each pending custom element (in tree order): 1. Create the instance objects for the custom element. 2. Increment CostomElementConstructionCounter 3. Call the constructructor for the custom element, passing the object instance as `this`. 4. Decrement CostomElementConstructionCounter Then we need to guard all DOM traversal and DOM mutation methods and throw if the counter is non zero. The point is that the timing of the constructor invocation is mostly not observable. If an implementation wants to invoke it as it builds the DOM that also works since there is no way to traverse the tree at that time. On Fri, Feb 14, 2014 at 1:50 PM, Dimitri Glazkov <dglazkov@google.com>wrote: > > > > On Fri, Feb 14, 2014 at 10:36 AM, Jonas Sicking <jonas@sicking.cc> wrote: > >> On Fri, Feb 14, 2014 at 9:25 AM, Dimitri Glazkov <dglazkov@google.com> >> wrote: >> > On Thu, 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. >> > >> > >> > I am not sure I fully understand how this will work. Let me try to >> repeat it >> > back and see if I got this right. >> > >> > Basically, we are modifying the tree construction algorithm to be a >> 3-pass >> > system: >> > >> > 1) Build a meta tree (each node in the tree is a meta object that >> represents >> > an element that will be constructed) >> > 2) Instantiate all elements by calling constructors on them >> > 3) Build the tree of elements from the meta tree. >> > >> > Right? >> >> I'd rather put it as: >> >> 1) Construct the objects, but rather than inserting them in their >> parents, remember which parent they should be inserted in. >> > > Sure, this is the meta tree construction. At the limit, if every element > is a custom element, then you're effectively building a tree of things that > remember where their respective elements need to be. > > >> 2) Call constructors on all elements >> > > Yup. > > >> 3) Insert elements in their parent >> > > Yup. > > >> >> So no need to construct any meta objects. >> > > Okay, we don't have to call them meta objects, but we need some storage to > remember where the element should go :) > > >> >> You can further optimize by only doing this for custom elements with a >> constructor. >> > > Interesting. What if the element's constructor decides to walk the DOM > tree or mutate it? What does it see? Are there holes for elements that > haven't yet been inserted, or are the elements just appended regardless of > their initial position in the tree? > > :DG< > -- erik
Received on Friday, 14 February 2014 19:04:04 UTC