Now we have event constructors the init*Event methods on recently introduced Event interfaces can be removed. It is no longer correct to support them for CustomEvent, ErrorEvent, ProgressEvent, etc.
Is the idea here that no one has shipped these APIs yet so author aren't using them?
We can't really remove them, they are already used widely in the wild :(
http://codesearch.google.com/codesearch#search/&q=init(Custom%7CError%7CMouse%7CProgress)Event%20lang:js&type=cs
This search comes up clean: http://codesearch.google.com/codesearch#search/&q=init(Error%7CProgress)Event%20lang:js&type=cs
(In reply to comment #4) > This search comes up clean: > > http://codesearch.google.com/codesearch#search/&q=init(Error%7CProgress)Event%20lang:js&type=cs We can certainly try to kill them :)
Obviously the ancient ones like initMouseEvent aren't going anywhere. But many of the new ones haven't even shipped in multiple browsers yet. Those are the ones that should go, e.g. almost all the ones in the HTML spec.
(In reply to comment #6) > Obviously the ancient ones like initMouseEvent aren't going anywhere. > > But many of the new ones haven't even shipped in multiple browsers yet. Those are the ones that should go, e.g. almost all the ones in the HTML spec. SGTM.
Purging initErrorEvent and initProgressEvent sounds great (probably can't with Custom, since I think some YUI stuff use it). There are probably some other ones we can kill as well (perhaps some of the ones we have added in the last few months, Composition?)
CloseEvent? MediaSteamEvent? WebGLContextEvent? PopStateEvent? PageTransisionEvent? The webkit version of MessageEvent?
Assuming we want to remove separate init*Event methods in separate patches, to make it easier to roll individual methods back in if it turns out they are used in the wild.
Should these events be removed from EventFactory.in at the same time? createEvent('ProgressEvent') does not seem useful without initProgressEvent, for example.
> Should these events be removed from EventFactory.in at the same time? createEvent('ProgressEvent') does not seem useful without initProgressEvent, for example. That will effect the JS wrapper selection as well. When the IDL says Event, the bindings actually return a wrapper for the actual type of the Event. EventFactory.in provides an enumeration of all the event interfaces. IMHO, there isn't anything to be gained by preventing these objects from being created by createEvent.
(In reply to comment #12) > That will effect the JS wrapper selection as well. When the IDL says Event, the bindings actually return a wrapper for the actual type of the Event. EventFactory.in provides an enumeration of all the event interfaces. > > IMHO, there isn't anything to be gained by preventing these objects from being created by createEvent. Got it. I will leave createEvent alone.
I have taken a look at all of the events in WebKit, the relevant specs, and whether the events are used (using Code Search.) Here is what I think we should do. For convenience I am just going to mention the event interface name, but I mean init*Event: These are ones we already removed: ErrorEvent (bug 71338), MediaStreamEvent (bug 71344), TrackEvent (never implemented) I think we can remove these: BeforeLoadEvent (bug 71636), CloseEvent (bug 71374), OverflowEvent, PageTransitionEvent, PopStateEvent, ProgressEvent (bug 71340), WebKitAnimationEvent, WebKitTransitionEvent We *might* be able to remove these: StorageEvent—used by Unhosted; HashChangeEvent—used by Ample SDK. I think we can remove these, but we need to file bugs against the specs to get the specs updated: AudioProcessingEvent, DeviceMotionEvent, DeviceOrientationEvent, WebGLContextEvent And for completeness, these are the untouchables—we can’t remove these, it seems hordes of people use them: CompositionEvent, CustomEvent (YUI), Event, KeyboardEvent, MessageEvent, MouseEvent, MutationEvent, TextEvent, TouchEvent, UIEvent, WheelEvent
On more careful inspection I am not sure whether YUI uses initCustomEvent. It has a method of its own, initCustomEvent*s*, that is unrelated but shows up in casual searches. However initCustomEvent is used in smaller frameworks such as Ample, JSDOM and "XBL" <http://codesearch.google.com/#search/&q=initCustomEvent%5B%5Es%5D%20lang:js&type=cs>
Fixed per dependencies.