W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: Better event listeners

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 14 Mar 2013 12:17:41 +0200
Message-ID: <5141A3C5.3080202@helsinki.fi>
To: David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>
CC: Anne van Kesteren <annevk@annevk.nl>, www-dom@w3.org, Yehuda Katz <wycats@gmail.com>
On 03/14/2013 11:48 AM, David Bruant 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.
I don't think there are too many use cases for async listeners and using setTimeout() is easy.

> I see Futures as a convenience (or "design pattern" maybe) written on top of events (the general idea of events, not necessarily the ones defined in
> the DOM). An object having mutually exclusive success/error events where at most one will be fired is pretty common and Futures makes an idiom out of
> this recurring pattern.
> But not all events follow this pattern. "readystatechange" is meant to be fired several times, for instance.

> If people want to make a future out of an upcoming existing event, they can do so in a few lines (as expressed here [1]). Maybe it will be a very
> common pattern for futures, but it's not certain.

> Maybe people will use that only for a handful of other events and we'll see a different pattern emerge.
> I'd be more in favor of shipping minimalistic futures, see how people use them and add hooks to DOM events after having a better understanding of how
> people use events in combination with Futures, but not before.
and agree even more.

Received on Thursday, 14 March 2013 10:18:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC