Re: innerHTML in DocumentFragment

Importantly, the context-less use-case is by far the common one when you're
constructing a DOM in JS.

On Fri, Nov 4, 2011 at 12:55 PM, Yehuda Katz <wycats@gmail.com> wrote:

> 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
>
>