Re: HTML5 dependencies on DOM3 Events

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

> On Jun 3, 2009, at 2:34 AM, Ojan Vafai wrote:
>
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.
>

I'm not too attached to this onExecCommand idea, but I do firmly believe
that mutation events are a bad solution for rich-text. Also, *in practice*,
rich-text is one of the primary (only?) real use-cases for mutation events.
We should come up with a better comprehensive solution for rich-text. Once
we've implemented that, I think we could eventually get away with dropping
mutation events entirely.

Maybe we should have different events for all the different ways that a user
can modify content in a rich-text region, but the end result is that nearly
every web page that wants to use rich-text would need to listen to all these
events for something as simple as detecting whether the content was
modified. While that's not the end of the world, it's also not ideal.

An input event makes sense for something like user typing. Other events make
sense for most other user actions (e.g. drop, paste, etc.). There are a
couple categories of user-initiated input that are left unaddressed (unless
I don't understand your oninput suggestion). A couple examples off the top
of my head:
-User types cmd/ctrl + b to bold.
-User clicks on the edit menu and does undo/redo


Here's a my argument for onExecCommand. I'm totally open to other ideas
though.

Currently, most rich-text code needs a considerable amount of code to
monitor changes in contentEditable regions and mis-uses mutation events as a
catchall for the cases where the browser doesn't fire an event.
onExecCommand provides a single event for rich-text code to monitor changes.
As I picture it, the event would have a name attribute (the name of the
command) and a range attribute (the DOM Range it modified, usually this
would be the current selection). It's similar to an onInput event, except
that it (a) conveys the semantic meaning of the user's action and (b) acts
on a Range/Selection, so does not need something expensive like a list of
what nodes/attributes were modified. In most rich-text libraries that I have
seen, an event like this would replace a good deal of code that listens to
quite a few events (key(down|press|up), cut, copy, paste, drop, etc.).

As for the performance concerns, it's considerably less noisy than mutation
events and doesn't have any of the string conversion costs. Also, since it
would replace the need to listen to many other events (e.g. key events), it
could perform better.

Ojan