For consistency, I've gone ahead and added DEPRECATION warnings for all init*Event methods with the exception of initEvent and initCustomEvent.

Deprecation implies you don't have to implement the method unless you want to for backwards compatibility (same definition as used for the Mutation and MutationName events.

I didn't remove (vs. deprecate) the init* events from the newly added interfaces because they already shipped in IE9, thus we _do_ have a need to continue to implement them and the definition of deprecated seemed to apply best to this scenario. But other implementations that want to claim conformance to this spec don't need to do so, especially with event constructors.

I also left the deprecation notes somewhat vague about "some future spec" defining them, since these particular event constructors aren't in DOM4 and Jacob's other draft isn't yet incorporated into charter.

Let me know if this action is acceptable.

I don't think that's acceptable. A standard should describe the end goal, not some inbetween state.

(In reply to comment #2)
> I don't think that's acceptable. A standard should describe the end goal, not
> some inbetween state.

Understand, but if I remove the init methods completely from CompositionEvent, and WheelEvent (TextEvent is gone), I'm going to get a bug later that says that "I cannot initialize the properties of a composition/wheel event!"

That's going to then lead to specifying event constructors as the only real alternative to bringing back the init methods.

I don't want to add event constructors because that's what DOM4 is introducing, and I don't want to be introducing new features to DOM3 events at this point in it's life. (Reminder: it needs to be finished!)

Marking these as deprecated was the best option I had. I'd rather have this spec finish with a deprecated set of init methods knowing that they may never be implemented in some user agents, versus finishing with a set of interfaces that don't support initialization at all.

How about adding a note that we're not adding them because we want to bring this spec to REC, but implementations will support them anyway because they're in the version of the spec currently in development?

(In reply to comment #4)
> How about adding a note that we're not adding them because we want to bring
> this spec to REC, but implementations will support them anyway because they're
> in the version of the spec currently in development?

That would be acceptable as long as you let me provide the API description in a non-normative section somewhere (say in an appendix)?

So you'd define event constructors non-normatively along with a reference to DOM4? Why not just point to the UI Events draft? But either way that seems fine to me. The event constructors follow naturally from the event interface so it's not like we can change them anyway once we agreed on the event interface.

(In reply to comment #6)
> So you'd define event constructors non-normatively along with a reference to
> DOM4? Why not just point to the UI Events draft? But either way that seems fine
> to me. The event constructors follow naturally from the event interface so it's
> not like we can change them anyway once we agreed on the event interface.

Oh, I misinterpreted your use of the word "them" as referring to init* methods. You were actually thinking of event constructors. I was actually planning on just moving the init* methods for CompositionEvent and WheelEvent to a non-normative appendix and describe them there for completeness, but perhaps just describing the event constructors in the same place non-normatively would be sufficient.

(In reply to comment #6)
> So you'd define event constructors non-normatively along with a reference to
> DOM4? Why not just point to the UI Events draft? But either way that seems 
> fine to me.

With the latest revision of the spec, I've axed the init* methods from all of the new event interfaces that were newly defined in DOM Level 3 Events:
* CustomEvent
* FocusEvent
* WheelEvent
* KeyboardEvent
* CompositionEvent
...and moved them into a non-normative appendix (now Appendix A) for historical reasons. Appendix A includes a description of the state of the world for these legacy init* methods as well as linking to DOM4 for the latest in event constructor guidance. To complete the package, I non-normatively describe the WebIDL for event constructors for the interfaces I listed previously and add:
* Event
* UIEvent
* MouseEvent
...to ensure that all interfaces that arent deprecated (i.e., MutationEvent and MutationNameEvent) have an event constructor described. This should allow the entrepreneurial user agent to use event constructors if desired. I also make it clear that DOM L3 Events doesn't require a conforming implementation to implement the legacy init* methods or the event constructors, though an implementation should probably implement one or the other to be sure that authors can initialize these event interfaces.

Appropriate deprecation notices were put on the init* methods that remain, to discourage their use, and indicate that they won't be back in a future standard. (I didn't include the notice on the Event interface since you are still describing it in DOM4.)

Please let me know if this is a satisfactory resolution of this bug.

I don't think we should suggest that fresh implementations are allowed to support the init* methods. It seems somewhat wrong to me to even allow them to be implemented given that a) that's not interoperable and b) the end goal is to remove them, but given that you feel strongly about mentioning them I guess I might be okay with that, but I don't want to give the impression they're okay.