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 00:12:55 -0700
Message-ID: <BANLkTi=N03+Xc8V8EdgRA3vTY_JO=7uSOg@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
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.

/ Jonas
Received on Friday, 24 June 2011 07:13:55 GMT

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