- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 24 Jun 2011 04:17:00 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
On Fri, Jun 24, 2011 at 12:12 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Jun 22, 2011 at 8:42 AM, Anne van Kesteren <annevk@opera.com> wrote: >> On Fri, 04 Mar 2011 11:25:45 +0100, Anne van Kesteren <annevk@opera.com> >> wrote: >>> >>> If we indeed introduce objects into our APIs and I start to think that >>> would make sense I think the simplest approach that could possibly work here >>> is to overload initEvent(). In addition to its three argument version it >>> would get a version that accepts just one argument, an object. From this >>> object property values are queried to set values on the event. E.g. >>> >>> var e = document.createEvent("CustomEvent") >>> e.initEvent({"type":"custom", "details":{"hello":"world"}}) >>> document.dispatchEvent(e) >> >> https://bitbucket.org/ms2ger/dom-core/changeset/b9bb17789db9 is the >> specification text for this. I suspect it will propagate to the editors' >> drafts soon. >> >> Instead of overloading initEvent() I went with a new method init() based on >> a suggestion from Olli. >> >> >> So for each new event interface we define (and hopefully some of the >> recently-added ones too) the init*Event() is not to be included and instead >> a dictionary that inherits from InitEvent is to be included, as well as how >> that dictionary maps to the event, as illustrated in DOM Core. > > Actually, the API I think we should aim for is: > > var e = new MouseEvent("mousemove", { bubbles: true, cancelable: false, ... }); > > The whole thing of passing a interface name as a string is pretty > ugly, and using create* factory functions rather than using proper JS > constructor is a leftover from the more Java-esque days. Additionally > the above API has the advantage of being one function call, rather > than two (similar to Garrett's proposal). > > The main problem with the above is feature testing. One way to feature > test that works but is pretty hacky is to test MouseEvent.length. This > should return 2 if the MouseEvent constructor takes 2 arguments (one > of which is optional). This test fails all the current browsers that I > tested (didn't check IE), so we could mandate in the spec that it > should pass once browsers support using these interface objects as > constructors. > > But there are of course other solutions for feature detection too. FWIW, another nice advantage of this syntax is that you can do: target.dispatchEvent(new MouseEvent("mousemove", {...}); and target.dispatchEvent(new CustomEvent("ello")); / Jonas
Received on Friday, 24 June 2011 11:17:57 UTC