- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 9 Jun 2014 11:03:55 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Mon, Jun 9, 2014 at 10:45 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Jun 9, 2014 at 7:02 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> MQL used callbacks in a trivial way that looked exactly like events, >> except they weren't, and because of that there were trivial >> incompatibilities with specific details of the event system in >> general. We're just fixing that by switching over to actually using >> an event. Are you suggesting that we should have instead kept MQL >> with a custom callback system that instead more carefully aped event >> semantics? > > Yes. That seems silly and fragile to me. What happens when we add or tweak the event system later? Or perhaps more relevant, tweak our *implementation* of the event system? In Chrome we've actually fixed eventing bugs that were relevant for MQL but didn't get copied over because it was separate code that people didn't think of. >> This makes MQL an EventTarget, yes, but I don't see that as adding >> complication - can you elaborate on your concern? It is now >> technically possible to add a listener in two ways (the legacy >> `mql.addListener(cb)` and `mql.addEventListener("change", cb)`), but >> that's just us covering the legacy case, and I don't see it as a big >> deal. > > I don't see a big need to add that API surface area. There's no need to do it, no. It's just a consequence of the change. You might have been misled into thinking this was some big purposeful change. It's not, it's a small consistency change. Its reasoning is just to make implementor code slightly more consistent, and to make author code that works on events be slightly more consistent. For example, if we add an EventStream a la <http://www.xanthir.com/b4PV0>, I expect to have a static method that converts an (EventTarget, event name) pair into an EventStream. That wouldn't work on MQL as previously specified, unless we add interface-specific hacks. The effects of the change are similarly small. The interface sprouts some nearly-duplicate methods, since EventTarget comes with methods with slightly different names and signatures. The precise semantics of the method change in very small ways related to relative ordering and duplication. ~TJ
Received on Monday, 9 June 2014 18:04:43 UTC