Re: innerHTML in DocumentFragment

My use-cases all want pure DOM nodes with no extra cruft added,
because they assume insertion into proper containers. This is true
about both jQuery and future updates to template content inserted in
the DOM.

For the use case of "give me nodes that I can insert into a regular
context and then serialize", perhaps a different API is in order?

Sent from my iPhone

On Nov 4, 2011, at 12:44 PM, Daniel Cheng <dcheng@chromium.org> wrote:

> 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:56:37 UTC