- 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