W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2011

Re: [DOMCore] Making event initializing easier

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 24 Jun 2011 04:17:00 -0700
Message-ID: <BANLkTi=16uCE5Z6GHJYN=Mq8=7awbeKOiQ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:07 GMT