- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 14 Mar 2013 12:10:19 -0700
- To: David Bruant <bruant.d@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, www-dom@w3.org, Yehuda Katz <wycats@gmail.com>
On Thu, Mar 14, 2013 at 2:48 AM, David Bruant <bruant.d@gmail.com> wrote:
> Le 13/03/2013 16:47, Jonas Sicking a écrit :
>
>> One tricky issue is the exact timing of the call to the .then
>> function. It would be great if we could enable the resolver function
>> to do things like call .preventDefault on the event, but that might
>> require that the .then function is called synchronously which goes
>> against [1].
>
> I consider that the DOM event model is absurdly broken. Namely, all
> listeners being called synchronously on .dispatchEvent is a bad idea.
> I don't think retrofitting Futures into that model is a good idea. Maybe a
> better idea would be to add a way for event handlers to be .dispatched
> asynchronously. That would fit in the Future model, but even then I'm not
> sure it's a good idea.
Adding something like
interface EventTarget {
...
Future<boolean> dispatchEventAtEndOfMicrotask(Event event);
}
is certainly doable, but unfortunately wouldn't fix the problem. We'd
still have the case that *some* events are fired synchronously.
We could of course say that any events that are fired synchronously
doesn't resolve the .once Futures. Or that they would trigger, but
they wouldn't have the ability to call .preventDefault() etc. Either
of these solutions seem very broken though.
/ Jonas
Received on Thursday, 14 March 2013 19:11:21 UTC