W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

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

From: Simon Pieters <simonp@opera.com>
Date: Mon, 07 May 2012 11:17:52 +0200
Message-ID: <op.wdxlf2zxidj3kv@simons-macbook-pro.local>
On Mon, 07 May 2012 10:58:00 +0200, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Mon, May 7, 2012 at 10:34 AM, Simon Pieters <simonp at opera.com> wrote:
>> On Fri, 04 May 2012 23:46:46 +0200, Ian Hickson <ian at hixie.ch> wrote:
>>> What does it do in the case of:
>>>
>>>   var frag = document.createDocumentFragment();
>>>   frag.innerHTML = 'bla bla .. 1GB of text .. bla <caption> bla' ?
>>
>> When hitting non-whitespace text, it seems better to use "in body", I  
>> think.
>
> That's potentially usable, since having non-whitespace inside a table
> is erroneous anyway.  However, it's less compatible with the <ruby>
> modes, as <ruby> can contain raw text.  Is that okay?

There is no ruby mode, AFAICT.

"in body":
[[
?A start tag whose tag name is one of: "rp", "rt"

If the stack of open elements has a ruby element in scope, then generate  
implied end tags. If the current node is not then a ruby element, this is  
a parse error.

Insert an HTML element for the token.
]]

It should probably just always generate implied end tags in the fragment  
case. (Is there content depending on it not generating implied end tags  
when parsing normally?)

Actually the spec already doesn't parse it right even with a context  
element, since it only checks the stack of open elements:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1512

-- 
Simon Pieters
Opera Software
Received on Monday, 7 May 2012 02:17:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT