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:


When following the spec
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

Reply via email to