Re: innerHTML in DocumentFragment

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
>

Received on Friday, 4 November 2011 19:16:22 UTC