- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 8 Nov 2011 11:26:41 -0800
- To: Dominic Cooney <dominicc@google.com>
- Cc: Travis Leithead <travis.leithead@microsoft.com>, Anne van Kesteren <annevk@opera.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <CANMdWTv8k2tsZTigRSjDj8=vqWaucD2pvuOHu17x_x_PkLC+iQ@mail.gmail.com>
That's exactly the point. Every API uses handleEvent even though they're not actually handling events (e.g. the IndexedDB callbacks use handleEvent). We should keep the platform simple for this weird edge case and use handleEvent everywhere. The only thing that changes is what arguments the callback takes. Each spec will still need to describe that. On Tue, Nov 8, 2011 at 11:21 AM, Dominic Cooney <dominicc@google.com> wrote: > I like this idea. [Callback(Event)] EventListener? seems more flexible > than Callback(Event) in that it can use a name other than handleEvent when > dealing with an object. > > Web Audio, for example, has a callback for processing audio buffers. > handleEvent is a weird name for this since it doesn’t handle events. > > What about (future) callbacks that have return types or raise exceptions? > > Dominic > > On Tue, Nov 8, 2011 at 10:04 AM, Travis Leithead < > travis.leithead@microsoft.com> wrote: > >> FWIW, I like the idea. The current indirection through an interface >> annotated with [Callback] has historically been hard for newbies to WebIDL >> to figure out. Anne's concept helps reduce the indirection. **** >> >> ** ** >> >> Another syntax could be:**** >> >> ** ** >> >> addEventListener(DOMString type, [Callback(Event)] EventListener? >> listener, optional boolean capture)**** >> >> ** ** >> >> Which re-uses the "constructor" parameter syntax (in an extended >> attribute) that we already have in WebIDL.**** >> >> ** ** >> >> *From:* ojan@google.com [mailto:ojan@google.com] *On Behalf Of *Ojan >> Vafai >> *Sent:* Tuesday, November 08, 2011 9:05 AM >> *To:* Anne van Kesteren >> *Cc:* public-script-coord@w3.org >> *Subject:* Re: [WebIDL] Simplify callbacks**** >> >> ** ** >> >> I support this. While it's not the API I'd design from scratch, I think >> it's what we're stuck with and the simplicity provided by doing this >> throughout the platform is worth it.**** >> >> On Tue, Nov 8, 2011 at 6:47 AM, Anne van Kesteren <annevk@opera.com> >> wrote:**** >> >> It seems that all callbacks use handleEvent() and we cannot change that >> at this point I think. We should simplify callback syntax to a) make IDL >> easier to read and b) ensure consistency throughout the platform. >> >> addEventListener(DOMString type, Callback(Event)? listener, optional >> boolean capture) >> >> >> -- >> Anne van Kesteren >> http://annevankesteren.nl/**** >> >> ** ** >> > >
Received on Tuesday, 8 November 2011 19:27:32 UTC