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

Re: [webcomponents] HTML Parsing and the <template> element

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 6 Jun 2012 13:50:24 +0300
Message-ID: <CAJQvAucbfdtTMk5NT0NW5G2xorYk0fksGok15n6SYjKqFJuZ-A@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Rafael Weinstein <rafaelw@google.com>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Erik Arvidsson <arv@google.com>, Yehuda Katz <wycats@gmail.com>
On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 4 Apr 2012, Rafael Weinstein wrote:
>> On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>> >
>> > Perhaps lost among other updates was the fact that I've gotten the
>> > first draft of HTML Templates spec out:
>> >
>> > http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
>> I think the task previously was to show how dramatic the changes to the
>> parser would need to be. Talking to Dimitri, it sounds to me like they
>> turned out to be less "open-heart-surgery" and more "quick outpatient
>> procedure". Adam, Hixie, Henri, how do you guys feel about the
>> invasiveness of the parser changes that Dimitri has turned out here?
> I think it's more or less ok, but it has the problem that it doesn't give
> a way to reset the insertion mode again while inside a <template>.

I still think that breaking the old correspondence between markup and
the DOM and shrugging the XML side off is a big mistake. Why would it
be substantially harder to check inertness by walking the parent chain
(which normally won't be excessively long) as opposed to checking a
flag on the owner document?

I strongly believe that this template contents should be children of
the template element in the DOM instead of being behind a special
wormhole to another document while parsing and serializing as if the
special wormhole wasn't there.

Henri Sivonen
Received on Wednesday, 6 June 2012 10:50:53 UTC

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