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: Anne van Kesteren <annevk@opera.com>
Date: Mon, 30 Apr 2012 17:43:15 -0700
To: "Rafael Weinstein" <rafaelw@google.com>
Cc: public-webapps@w3.org, "Ryosuke Niwa" <rniwa@webkit.org>, "Yehuda Katz" <wycats@gmail.com>, Ms2ger <ms2ger@gmail.com>, "Henri Sivonen" <hsivonen@iki.fi>
Message-ID: <op.wdltmdil64w2qv@annevk-macbookpro.local>
On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein <rafaelw@google.com>  
> 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
> 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.

The "Any other * tagName" design also seems somewhat fragile to me. I  
think those lists need to be explicit and coordinated. We should at least  
put some checks in place to make sure we are not introducing more  
overlapping element names in the future.

Also, I looked briefly at the WebKit patch (which does not appear to  
address the hairy "Any other * tagName" issue), DOM4 is not responsible  
for innerHTML. http://html5.org/specs/dom-parsing.html is and is written  
by Ms2ger (in case the "move forward" in your question was about defining  
this in DOM4).

Anne van Kesteren
Received on Tuesday, 1 May 2012 00:43:58 UTC

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