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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 30 Apr 2012 18:51:26 -0700
Message-ID: <CAAWBYDC+87C=YQax1TqVrcA0FNiBq88zvMmAvCQqBzuGA5x3Sg@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Rafael Weinstein <rafaelw@google.com>, public-webapps@w3.org, Ryosuke Niwa <rniwa@webkit.org>, Yehuda Katz <wycats@gmail.com>, Ms2ger <ms2ger@gmail.com>, Henri Sivonen <hsivonen@iki.fi>
On Mon, Apr 30, 2012 at 5:43 PM, Anne van Kesteren <annevk@opera.com> wrote:
> 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.

This is simply invoking the fragment parsing algorithm that's already
defined in DOMParsing, but intelligently supplying a context element.
There's no need to worry about emitting tokens or anything, except
insofar as DOMParsing already has to worry about that.

> 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.

I'm fine with that, as long as implementations are okay with updating
their lists of elements as the underlying languages (SVG and MathML)
change.  This *will* potentially cause a behavior difference, as
elements that previously parsed as HTMLUnknownElement instead parse as
some specific SVG or MathML element.

~TJ
Received on Tuesday, 1 May 2012 01:52:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT