- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 24 Jul 2011 11:18:33 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>
- Cc: Dave Raggett <dsr@w3.org>, Ryosuke Niwa <rniwa@webkit.org>, David Flanagan <dflanagan@mozilla.com>, public-webapps@w3.org
On Fri, Jul 22, 2011 at 11:54 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Actually, you can pretty easily do it in the other order (move the text into > the <b>, and then put the <b> in the DOM), and may want to so as to minimize > the number of changes the the live DOM; that's something that's often > recommended as a performance enhancement. Hmm. Interesting. So far I've been writing my draft on the theory that my "move preserving ranges" operation would actually be implemented as I've specced it, so that all Ranges (not just the current selection) would remain in logically the same place after the DOM operations. The way I've designed it, you have to move stuff around within the tree rather than removing and re-adding it. But of course, that design could always be changed. Either I could just give up on preserving anything other than the current Selection, or I could define different primitives. So point taken. Editing doesn't *have* to involve moving nodes at all. > I don't need software that uses mutation events. I need software that > triggers editing operations, so I can them actually measure what DOM > mutations are performed in the course of these editing operations. What use do you have here for software that doesn't want to use DOM mutations to start with? The question is what users of mutation handlers will need, right? If you do need such software, though, some of the most important WYSIWYG editors out there are TinyMCE and CKEditor, which have easy-to-use online demos: http://tinymce.moxiecode.com/ http://ckeditor.com/ A typical workload is paste in the contents of some blog post or other that you grab from someplace (often this would come preloaded if you're editing or quoting an existing post), then change around some text, type a couple of paragraphs, add an image or some smilies or something, make some links, that sort of thing. On Fri, Jul 22, 2011 at 6:57 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Fri, Jul 22, 2011 at 2:08 AM, Dave Raggett <dsr@w3.org> wrote: >> But if you are going to, *don't* coalesce mutations when the resulting DOM >> tree is dependent on the order in which those mutations took place. This is >> critical to distributed editing applications. > > The DOM should have no such behavior. The only exception to this rule > that I know of is <script> elements. They execute their contained > script the first time they are inserted into a Document, but don't > "undo" that action when removed (for obvious reasons), nor do they > redo it when inserted again. The order of mutations makes a big difference if you're recording them as things like "insert node X into node Y at offset Z". If you append two children to a given node, the order you append them in will affect the resulting DOM. Likewise if you insert two nodes at the same index, or before the same existing child, or if you insert two nodes at particular indices but remove some child in between. How could you record arbitrary DOM mutations such that the order wouldn't matter in general? On Fri, Jul 22, 2011 at 6:58 PM, Jonas Sicking <jonas@sicking.cc> wrote: > We should have much richer events to aid with rich text editing. Using > mutation notifications for this is will not create a good experience > for the page author. Agreed. I'd be really interested in specific use-cases if people are using mutation events for editing here.
Received on Sunday, 24 July 2011 15:19:20 UTC