Re: HTML5 dependencies on DOM3 Events

On Fri, Jun 5, 2009 at 9:26 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Daniel Danilatos wrote:
>
>> For our uses (Google Wave) I'd be happy with batched mutation events as
>> long as they contain enough information to reverse their effects.
>>
>
> Note that mutation events as currently specified do not, by the way....
>

Sure, they have enough to get by, (again would prefer not to depend on
them).


>
>
>  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.
>>
>
> Which sounds like a pretty distinct use case from what a lot of other
> people want, which is knowing when some other script does something else to
> the DOM.
>

I think a lot of people are relying on mutation events for something they
weren't intended for, because there is no better alternative. Anything
involving text editing generally runs into this. For example, from reading
the bug reports to do with IMEs on mozilla, people want to know when the dom
is being changed by the editor, for text fields & content editable regions
as well. People are falling back on mutation events to deal with some of
these issues; but I think that if we had comprehensive events for everything
the browser itself does, then the only need for mutation events would be the
use case you mentioned, to know if the DOM is being programmatically changed
by some script.


>
> It also sounds like you don't care about modifications to random parts of
> the DOM, but specifically to the DOM inside a contentEditable region, right?


Yes, there are a couple of small exceptions where we use them for the "is
some code changing our DOM" use case, but by and large we use them as a fall
back for lack of other events, where the browser is randomly modifying the
DOM in a contentEditable region without warning.


>
>
>  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).
>>
>
> Yeah, it really doesn't sound like mutation events are the ideal mechanism
> here.  Thank you for explaining the use case!


No problem! Thanks for the feedback. Looking forward to coming up with a
solution :)

Dan


>
>
> -Boris
>
>