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
