On Fri, Feb 14, 2014 at 10:36 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Fri, Feb 14, 2014 at 9:25 AM, Dimitri Glazkov <dglaz...@google.com> > wrote: > > On Thu, Feb 13, 2014 at 6:50 PM, Jonas Sicking <jo...@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<
