- 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>
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
impossible.
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"}})
document.dispatchEvent(e)
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
sense.
* 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
over.
Interested to hear what you all think!
--
Anne van Kesteren
http://annevankesteren.nl/
Received on Friday, 4 March 2011 10:26:20 UTC