W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2011

Re: [DOMCore] Making event initializing easier

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 9 Mar 2011 17:39:53 -0800
Message-ID: <AANLkTikCxx=+UMUTj69OiHs8od4CwNkYsHt+Dr7LhrbT@mail.gmail.com>
To: Erik Arvidsson <arv@chromium.org>
Cc: Alex Russell <slightlyoff@google.com>, Anne van Kesteren <annevk@opera.com>, "www-dom@w3.org" <www-dom@w3.org>
On 3/9/11, Erik Arvidsson <arv@chromium.org> wrote:
> On Wed, Mar 9, 2011 at 06:58, Alex Russell <slightlyoff@google.com> wrote:
>> On Fri, Mar 4, 2011 at 2:25 AM, 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)
>>
1000% better than the existing event synthesis API. What is wrong with
it? What can be done to refine and improve it?

Is "CustomEvent" type the only reason that the Event interface type
must be specifed? I know "click" is a MouseEvent; Why do I really need
to say that in the code?

Other possibilities:
I. Make a createInitedEvent method.

var e = document.createInitedEvent( { type: "click", detail : 1 } );

Pros:
Easy to feature test on granular levels.
Less verbose; eliminating one step of code.

Cons:
?

II. Make a method to dispatch an initialized event.
node.dispatchInitedEvent( { type : "click" } );

>> I'd prefer something even more direct, moving away from "create*"
>> methods entirely and using "new" instead. E.g.:
>>
>> var e = new CustomEvent({ type: "custom", details: { hello: "world" }});
>> someNode.dispatch(e);
>

There, the Event interface name is represented as a constructor.

> Yeah, making DOM interfaces constructable is something that is a clear
> win from JS.
>
Why?

> With ES.next having support for destructuring assignment I believe we
> will see more objects-as-named-parameter patterns in library code so
> making the DOM follow suite is a win.
>
> I would actually take this one (or two) steps further. The CustomEvent
> interface is pretty useless in JS. Event objects are not sealed in JS
> so adding custom meta data is trivial.
>
> var event = new Event("type");

Incompatible with browsers today. Would require try catch to be used
in a feature test.
-- 
Garrett
Received on Thursday, 10 March 2011 01:40:28 GMT

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