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

[DOMCore] Making event initializing easier

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 04 Mar 2011 11:25:45 +0100
To: "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <op.vrtdw5pn64w2qv@anne-van-kesterens-macbook-pro.local>
In general I would like to refrain from introducing new features at this  
stage, but the initXXXEvent() pattern is problematic and it would be nice  
if we can avoid it for all new event interfaces. It is problematic for  
these reasons:

  * You have to remember and set all the arguments each time.
  * It makes extending existing event interfaces with new features  

If we can introduce a new design now we can avoid proliferating new event  
interfaces with initXXXEvent() and slowly move away from that design.

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"}})

These are the reasons why I prefer this design over settable attributes or  
a constructor-based approach:

  * It is a very minimal change from the existing model. The existing model  
is not great, but it is what we have and deviating away from it far for a  
feature mostly used for debugging is not worth it. Even if not just used  
for debugging the above is not much more complex than what libraries offer.
  * With settable attributes it becomes a little messier to also unset  
several flags at the same time. You would always want to unset the  
"trusted flag" for instance. (An alternative would be to not allow  
initializing already dispatched events (possibly scoped to trusted  
events), but that is not what implementations do.) Depending on the  
outcome of the other thread we might also want to reset the "stop  
propagation flag", "stop immediate propagation flag", and "canceled flag"  
here. Having these as side effect of initEvent() makes sense. Having them  
as side effect of setting the offsetX or type attribute makes a lot less  
  * In order for the constructor-based approach to work well you would want  
this kind of object-approach as well. Otherwise you have the same issues  
with having to remember all the arguments and making extensibility  
difficult. It seems therefore better to first experiment on a somewhat  
smaller scale (just initEvent(object)) than introducing constructors all  

Interested to hear what you all think!

Anne van Kesteren
Received on Friday, 4 March 2011 10:26:20 UTC

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