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: Thu, 26 Apr 2012 10:23:39 -0700
Message-ID: <CAAWBYDDtSBhsn9sEo0Ge9G_oge3bCR6Mw13A0txowwMfA-NEmg@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Ryosuke Niwa <rniwa@webkit.org>, Yehuda Katz <wycats@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>
On Thu, Apr 26, 2012 at 1:26 AM, Simon Pieters <simonp@opera.com> wrote:
> On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein <rafaelw@google.com>
> wrote:
>> Any other HTML tagName => HTMLBodyElement
>
> Isn't this one redundant with the last step?

No, this captures known HTML tagnames, so that HTML can lay claim on
the few tags that overlap with SVG.  The last step just captures any
remaining tags that fell through the cracks, so they can become
HTMLUnknownElements.


>> Any other SVG tagName => SVGElement
>> Any other MathML tagName => MathElement
>
> What are these two, exactly? The parser currently doesn't have a list of
> SVG/MathML tag names, and the SVG WG didn't like it when it was proposed to
> use a fixed list of SVG tag names for parsing SVG in text/html, IIRC.

We don't need a specific list in the spec, but each browser would need
one, constructed from whatever elements they currently understand.

(In my dreams, we just merge SVG into the HTML namespace, and then
this step disappears.)


> Also note that innerHTML on non-HTML elements currently always parses in the
> "in body" insertion mode. I'd like to see that fixed before we try to
> support foreign content in contextless innerHTML.
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635

Yes, that needs to be fixed.  As Ms2ger said yesterday in IRC, the
DOMParsing spec already handles this appropriately, but HTML needs a a
fix, since the former hooks into the latter.

~TJ
Received on Thursday, 26 April 2012 17:24:37 GMT

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