W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: innerHTML in DocumentFragment

From: Daniel Cheng <dcheng@chromium.org>
Date: Fri, 4 Nov 2011 12:44:29 -0700
Message-ID: <CAF3XrKp3Vv+wtGTBCRa+U4ki9Y-q5ju0Gyi7jnYpC10A4J3N0w@mail.gmail.com>
To: Yehuda Katz <wycats@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, João Eiras <joaoe@opera.com>, public-webapps WG <public-webapps@w3.org>
On Fri, Nov 4, 2011 at 12:15, Yehuda Katz <wycats@gmail.com> wrote:
> Sent from my iPhone
>
> On Nov 4, 2011, at 11:55 AM, Daniel Cheng <dcheng@chromium.org> wrote:
>
>> On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> 2011/11/4 Daniel Cheng <dcheng@chromium.org>:
>>>> In that example, there was a clear context element though--I'd argue
>>>> that Range.createContextualFragment should have been used instead.
>>>>
>>>> It seems like the general use of such a function would be to add some
>>>> nodes from a snippet of HTML markup into a div for example, where
>>>> synthesizing the correct context elements would make more sense.
>>>
>>> Sorry, I referred only to Yehuda's first example for simplicity.
>>> Please read the rest of Yehuda's first post, as his later examples
>>> both (a) break (or at least become unnecessarily difficult) if
>>> contextual wrappers are automatically added, and (b) don't have a
>>> context element to apply at the time the DOM is being constructed.
>>>
>>
>> I see. I think I understand this particular use case and why
>> contextual wrappers would make it harder.
>>
>>> If one is adding nodes into a div, one would *not* write:
>>>
>>> var frag = parse("<tr><td>foo</tr>")
>>> div.appendFragment(frag);
>>>
>>> ...because that would be nonsensical.  In particular, jQuery does
>>> *not* do anything special when they see this sort of pattern - they go
>>> to some effort to ensure that the fragment contains only the <tr> and
>>> descendants, and then would directly insert it into the DOM as a child
>>> of the <div>.
>>>
>>> ~TJ
>>>
>>
>> That being said, why is it non-sensical? If I were writing a rich text
>> editor that accepted pastes or allowed drag and drop editing, it seems
>> like a perfectly reasonable thing to create a fragment from the markup
>> and then insert it at the appropriate point. I originally suggested
>> synthesizing wrappers because if a page ended up serializing and
>> saving potentially invalid markup, then it might not render properly
>> later. You could, of course, argue that the appropriate context nodes
>> should have been present in the markup to begin with.
>
> Isn't that an argument for changing the in-body insertion mode, or
> perhaps creating a new insertion mode for contenteditable?
>
>>
>> Daniel
>>
>

I don't think it's an argument for changing in-body insertion mode,
since it feels like a return to the tag soup days of HTML. And simply
making contenteditable special doesn't help either--what if you have a
read-only view of the data?

Daniel
Received on Friday, 4 November 2011 19:45:08 GMT

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