Re: Mutation events replacement

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