Re: HTML5 dependencies on DOM3 Events

Hey guys

On Thu, Jun 4, 2009 at 8:37 PM, Maciej Stachowiak <mjs@apple.com> wrote:

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

For our uses (Google Wave) I'd be happy with batched mutation events as long
as they contain enough information to reverse their effects. That said, I'd
much rather not rely on mutation events at all, and instead have it so that
we get complete, cancellable, intent-informing events *before* the browser
does things to the dom. IME input and undo/redo are obvious examples (though
I understand there is something being spec'd out for undo/redo).

The key issue we have is that we edit our own semantic model, that is
rendered as HTML, and maintain a delicate mapping between the two. Thus we
need to be 100% in control of what the native editor does to the HTML dom in
a contentEditable region (currently DOM Mutation events are used as an
unpleasant catch-all).


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