Re: HTML5 dependencies on DOM3 Events

On Jun 3, 2009, at 2:34 AM, Ojan Vafai wrote:

> On Wed, Jun 3, 2009 at 5:59 PM, Doug Schepers <schepers@w3.org> wrote:
> Ian Hickson wrote (on 6/1/09 7:37 PM):
> HTML5 has the following dependencies on DOM3 Events:
>
> * Mutation events
>   There are a number of parts of HTML5 where what HTML5 should say  
> depends
>   on what happens with mutation events in DOM3 Events. (My preference
>   would be for mutation events to be either replaced wholesale or made
>   asynchronous, so that they are queued on the event loop instead of  
> being
>   fired as the changes happen, since the latter can result in serious
>   complexities and makes it very hard to maintain invariants during  
> the
>   execution of algorithms.)
>
> I also prefer this, but have heard that it breaks some existing  
> code, and doesn't do what some authors want.  I'll to to come to  
> consensus on the best option here.

The way mutation events work now makes all core DOM operations slower  
and more fragile if you implement it. I'm curious what existing code  
is broken.

>
> I wonder how many of the cases of what authors want would be better  
> served by higher-level APIs. For example, Google Wave is a very  
> heavy user of mutation events to track user input. But they use  
> mutation events because they happen to be the only thing that  
> captures all text input that users make. In practice, mutation  
> events are too noisy and too low-level for their needs, but they  
> serve as a catchall. They'd much rather have something that  
> expresses higher-level actions.
>
> For example, one idea we came up with for their use case is having  
> something like a cancellable onExecCommand event that would fire  
> whenever an execCommand was called and to spec it such that all text  
> editing is required to go through an execCommand (e.g. undo, redo,  
> insertText, bold, etc). These are much higher-level and less noisy  
> than mutation events and wouldn't have a number of problems that  
> mutation events do (e.g. performance penalties, crashiness  
> complexities, etc).

I'm not sure it makes sense to mandate that user typing or other  
direct manipulation (say, dragging a selection) acts as if execCommand  
had been invoked. I think it may make more sense to have an event  
similar to HTML5's oninput on <input elements> also available on  
contentEditable regions. That's pretty abstract, so it doesn't have to  
be tied to execCommand, but it can be spec'd to fire whenever the  
contents change for any user-initiated reason, with the option to  
coalesce for changes in rapid succession.

Regards,
Maciej