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