W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

From: Scott González <scott.gonzalez@gmail.com>
Date: Thu, 10 May 2012 19:27:22 -0400
Message-ID: <CAO8i3ieP9bgbnP3JVz1aNvgpxKPdD4Cum54gwH3LOWh5GEJYqw@mail.gmail.com>
To: Rafael Weinstein <rafaelw@google.com>
Cc: Ian Hickson <ian@hixie.ch>, "Tab Atkins Jr." <jackalmage@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, Yehuda Katz <wycats@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Henri Sivonen <hsivonen@iki.fi>, Webapps WG <public-webapps@w3.org>
On Thu, May 10, 2012 at 7:15 PM, Rafael Weinstein <rafaelw@google.com>wrote:

> On Thu, May 10, 2012 at 4:01 PM, Ian Hickson <ian@hixie.ch> wrote:
> > If we're going to do that, then we don't need any lookahead at all. We
> > should support literally that: parsing one element and its descendants.
> We
> > determine what element is being generatd by looking at the top of the
> > string ("<div ..." -> it's a div, "<tr ..." -> it's a tr, etc), and we
> > parse until that element is popped from the stack or the end of the
> string
> > is reached. This avoids all the problems with doing magical lookahead.
> This was more or less Yehuda's original proposal. If we can make this
> work, I think it also solves the problem and would be acceptable. My
> sense is that this solution probably introduces more complexity into
> the parser and it's output isn't any superior.

Yehuda has actually been complaining about this limitation for quite a
while. I know that he would not consider this a full solution.
Received on Thursday, 10 May 2012 23:27:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC