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: Rafael Weinstein <rafaelw@google.com>
Date: Thu, 26 Apr 2012 21:58:49 -0700
Message-ID: <CABMdHiSVjsb3zb7kVcfGtwNftU_EUsCqey9va-xpNgcib+XQuw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Henri Sivonen <hsivonen@iki.fi>
Cc: Simon Pieters <simonp@opera.com>, Ryosuke Niwa <rniwa@webkit.org>, Yehuda Katz <wycats@gmail.com>, Webapps WG <public-webapps@w3.org>

Does this address the concerns you raised earlier?

On Thu, Apr 26, 2012 at 10:23 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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 Friday, 27 April 2012 04:59:19 UTC

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