Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

Henri,

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