On Fri, Nov 4, 2011 at 12:15, Yehuda Katz <[email protected]> wrote: > Sent from my iPhone > > On Nov 4, 2011, at 11:55 AM, Daniel Cheng <[email protected]> wrote: > >> On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. <[email protected]> wrote: >>> 2011/11/4 Daniel Cheng <[email protected]>: >>>> 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
