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: Rafael Weinstein <rafaelw@google.com>
Date: Thu, 10 May 2012 16:51:51 -0700
Message-ID: <CABMdHiTu3xYWHTjmUhaHRbfNQ46hRiJNButRF51nWuHw9nx7_A@mail.gmail.com>
To: Scott González <scott.gonzalez@gmail.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 4:27 PM, Scott González
<scott.gonzalez@gmail.com> wrote:
> 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.

Ah, sorry. I didn't quite understand Hixie's proposal. I retract my
statement -- this isn't a workable solution.

Also, I'm curious why it's ok to peak at the first few characters of
the string, and not ok to peak at the token stream until we see the
first start tag?
Received on Thursday, 10 May 2012 23:52:20 UTC

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