- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Wed, 13 Mar 2013 18:04:34 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Anne van Kesteren <annevk@annevk.nl>, www-dom@w3.org, Yehuda Katz <wycats@gmail.com>, slightlyoff@google.com
* Jonas Sicking wrote:
>The exact syntax here is of course to-be-determined, but the idea is
>that it's the exact same syntax as the "on" function, except that it
>doesn't take a handler-function argument. Instead a Future is returned
>and this future is resolved (using the Event object) the first time
>the corresponding "on" handler-function would have been called.
>
>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].
>
>[1] https://github.com/slightlyoff/DOMFuture
Could you elaborate on where you see the problem here? If you can't get
your code called at the same time your .addEventListener code would be
called, then such a feature would seem worse than useless. The primary
utility in having "futures everywhere" would be to support higher-level
protocols that use them, like <http://taskjs.org/>, or simply something
like, using your syntax,
var event = await elem.once("event");
...
which should be essentially equivalent to
elem.addEventListener("event", function(event) {
...
}, false);
My own http://lists.w3.org/Archives/Public/www-archive/2008Jul/0009.html
ensures this by resuming execution from the .addEventListener callback.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Wednesday, 13 March 2013 17:05:07 UTC