Re: HTML5 dependencies on DOM3 Events

Hi, Ojan, Daniel-

Ojan Vafai wrote (on 6/3/09 5:34 AM):
> On Wed, Jun 3, 2009 at 5:59 PM, Doug Schepers <schepers@w3.org
> <mailto: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.

Yes, I think that most of the uses for mutation events today are because 
the author doesn't have some better method of doing what they want to 
do.  If we gather use cases and requirements, we shoudl be able to 
better satisfy them.


>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 talked with Daniel (from the Wave team) about this briefly at Google 
I/O, and we agreed we should come up with some better solution that 
doesn't use mutation events.

If someone is willing to write up a more detailed explanation of an 
alternate model, we can talk about it on this list and during the DOM3 
Events telcons, and I will write it up into spec text and put it in the 
spec.

Daniel was interested  in joining the telcons, so let's find a suitable 
time and day for all the attendees.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 3 June 2009 16:49:21 UTC