Re: innerHTML in DocumentFragment

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.

Daniel

Received on Friday, 4 November 2011 18:54:50 UTC