Bugzilla – Bug 15259
Last modified: 2012-11-28 14:31:56 UTC
In the DOM4 specification, the interface of CustomEvent (found at http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#customevent) contains only one member: "readonly attribute any detail;" The DOM3EVENTS specification declares one more method overload, "initCustomEvent(DOMString type, bool bubbles, bool cancelable, any detail);". (This can be found at http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-CustomEvent)
I know that the initEvent method is made obsolete due to the fact that in DOM3 you are introducing Event constructors, but as long as they're not actually depreciated, shouldn't you keep them simply for backwards-compatibility? At the very least, shouldn't you keep initCustomEvent for the same reason that you are keeping initEvent, or if you need to get rid of one, then unify the change and get rid of both?
The reason that we're keeping initEvent is compatibility with deployed content (prototype.js, for example: <https://github.com/sstephenson/prototype/blob/master/src/prototype/dom/event.js#L956>); I rather doubt that reason applies as much to initCustomEvent.
(In reply to comment #1)
> The reason that we're keeping initEvent is compatibility with deployed content
> I rather doubt that reason applies as much to initCustomEvent.
A couple of smaller frameworks use initCustomEvent:
I’m not sure if these are sufficient justification for keeping initCustomEvent around or not. However it is more use than other init*Event (eg initProgressEvent) methods get (at least in the indexable, open source space.)
Lets keep this open until we know it has been removed from some implementations.
Okay, it's back in:
Dominic, your name will be added to the acknowledgments next checkin as I forgot it this time.