- From: Adam Klein <adamk@chromium.org>
- Date: Tue, 18 Feb 2014 16:12:02 -0800
- To: Dimitri Glazkov <dglazkov@google.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, Ryosuke Niwa <rniwa@apple.com>, Erik Arvidsson <arv@chromium.org>, WebApps WG <public-webapps@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, William Chen <wchen@mozilla.com>
On Tue, Feb 18, 2014 at 3:26 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
> On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov <dglazkov@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
Received on Wednesday, 19 February 2014 00:12:30 UTC