On Tue, Feb 18, 2014 at 3:26 PM, Dimitri Glazkov <dglaz...@google.com> wrote: > On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking <jo...@sicking.cc> wrote: > > On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov <dglaz...@google.com> > > wrote: > > > The thing that really bothers me is that this approach is contradicting > > > itself. We go to into pretty elaborate lengths to enable running > > > constructors during parsing, but the key performance lesson developers > > > will > > > immediately learn is to avoid constructors on custom elements, because > > > they > > > will trigger the two-phase code path during parsing. Here's a thing that > > > you > > > can use, but you probably don't want to ever use it. > > > > The above paragraph appears to assume that creating this list is slow. > > Do you have data to back that up? > > No, of course not :) It's a first intuitive reaction.
One example that seems intuitively problematic about this approach (to me, anyway) are those parts of the parser that inspect the tree during parsing: foster parenting. I'm not sure it's a performance issue so much as a complexity issue. Consider: <div> <my-element> <table> <div> When following the spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#appropriate-place-for-inserting-a-node), any text in that algorithm which says "parent node" need to be patched to say something about this new list of to-be-attached nodes. Patching all such references seems likely to be difficult and error-prone, but I admit that I can't quantify those worries. - Adam