- From: John Barton <johnjbarton@google.com>
- Date: Mon, 17 Jun 2013 15:38:24 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>, "www-dom@w3.org" <www-dom@w3.org>
- Message-ID: <CA+2jLuKOXAbogYJsLKPwLwU-0usRVTNiOhHMj23LDiEfS+PFFA@mail.gmail.com>
On Mon, Jun 17, 2013 at 2:27 PM, Ian Hickson <ian@hixie.ch> wrote: > On Mon, 3 Jun 2013, Jonas Sicking wrote: > > > > I think it would be great if dispatchEvent dispatched the event at > > end-of-microtask or some such. > > The usual pattern when dispatching an event is: > > <something happens> > dispatch an event to notify user code! > was the event canceled? if not, do the default action > > It would be weird if this wasn't synchronous. I'm not really sure how you > would do the default action. Certainly it would mean that the default > action was no longer in the same task as the <something happens>, which is > weird. Think about browser events (either by analogy or as a concrete > example, depending on whether you'd want this to apply to all events or > only those dispatched from script): you click on a checkbox, its .value > changes, an event is fired, and if it's canceled, the .value is changed > back. It'd be pretty weird if this happened asynchronously. > Check-boxes are changed asynchronously (by XHR processing) all of the time. On the other hand, the control flow options in dispatchEvent() are -- compared to the rest of JS -- weird. With preventDefault any handler can block one special kind of action. With stopPropagation any handler can block a subset of other handlers. These feature are valuable, but if we're talking weird JS control flow, they are weird. (If we have a 'cancelable' flag allowing the dispatching caller to grant a handler the ability to preventDefault, I don't understand why we can't have a 'unexceptional' to grant handlers the ability to stop all handlers and throw in the caller.) jjb
Received on Monday, 17 June 2013 22:38:51 UTC