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: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 1 May 2012 11:46:16 -0700
Message-ID: <CA+c2ei92H2XVSnVzjgPbAQGPoLpD61XH1Fr+wEyyStwK9x72HA@mail.gmail.com>
To: Ms2ger <ms2ger@gmail.com>
Cc: Anne van Kesteren <annevk@opera.com>, Rafael Weinstein <rafaelw@google.com>, public-webapps@w3.org, Ryosuke Niwa <rniwa@webkit.org>, Yehuda Katz <wycats@gmail.com>, Henri Sivonen <hsivonen@iki.fi>
On Tue, May 1, 2012 at 3:29 AM, Ms2ger <ms2ger@gmail.com> wrote:
> On 05/01/2012 02:43 AM, Anne van Kesteren wrote:
>> On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein
>> <rafaelw@google.com> wrote:
>>> There aren't any parser changes required. DocumentFragment.innerHTML
>>> can still provide the "fragment case" with a context element and
>>> procede normally. It's not obvious to me what bug to open against
>>> HTML.
>>> Anne, can we move forward with this?
>> I personally think it would be better if HTML kept defining all entry
>> points to the HTML parser. And at least conceptually this is a new
>> insertion mode I think contrary to what you suggest in
>> http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html
>> as only insertion modes handle emitted tokens. And although I guess it
>> does not matter here for now, given that the tree builder can change the
>> behavior of the tokenizer decoupling them seems rather odd to me.
> I agree with Anne's point here; I'd rather not try to spec something more
> complex than invoking an algorithm in the HTML spec in DOMParsing.

I would also agree with that.

However I think that's only a realistic option if the HTML editor is
willing to add such a parser mode to the HTML spec. Otherwise I think
we're left with the option that Rafael describes.

/ Jonas
Received on Tuesday, 1 May 2012 18:47:16 UTC

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