W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2009

Re: HTML5 dependencies on DOM3 Events

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 3 Jun 2009 18:34:35 +0900
Message-ID: <78dc8440906030234ie0a1aebtac8b42d449a310ab@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: Ian Hickson <ian@hixie.ch>, www-dom@w3.org, Daniel Danilatos <danilatos@google.com>
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.

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

Received on Thursday, 4 June 2009 10:30:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC