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

Re: [DOMCore] Making event initializing easier

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Mon, 27 Jun 2011 17:52:54 +0300
Message-ID: <4E089946.4060303@helsinki.fi>
To: Jonas Sicking <jonas@sicking.cc>
CC: Anne van Kesteren <annevk@opera.com>, "www-dom@w3.org" <www-dom@w3.org>
On 06/24/2011 02:17 PM, Jonas Sicking wrote:
> 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", {...});

Handling of UI events with this new syntax needs to be defined somewhere 
first. Especially event.pageX/Y. The value of those depend on the 

> and
> target.dispatchEvent(new CustomEvent("ello"));
> / Jonas
Received on Monday, 27 June 2011 14:53:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:17 UTC