It seems Gecko successfully removed that method. Why should we add it? I don't think things need to make sense for document.createEvent() users.

I mean sites that use document.createEvent('messageevent') will most likely break if initMessageEvent doesn't exist. But if Gecko's experience is that the breakage is small enough and Blink is successful with removing it also, then sure, but then I think there's no point in having document.createEvent('messageevent') in DOM either.

https://bugzilla.mozilla.org/show_bug.cgi?id=848294
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/H6lsGFqdy3Y

Its strange that this list was extended:
https://github.com/whatwg/dom/commit/333b03cf6454e803d6433673c33f1292821dac0a

Before we have only:
CustomEvent
Event
MouseEvent
UIEvent

Now:
CustomEvent
Event
KeyboardEvent
MessageEvent
MouseEvent
TouchEvent
UIEvent

Event, MouseEvent and UIEvent has defined init*methods in D2E spec so still may be acceptable. Now DOM (only for Event and CustomEvent) and D3E (draft) define some other init*methods:

https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#legacy-event-initializers

The level of support these methods by different browsers is really chaotic and probably the only constructors finally change this situation.

Without dedicated initializer we can only use universal initEvent() and dispatch this event, but in practice (without posibility set some properties) its nonsens.

And for TouchEvent we have this in spec. (https://dvcs.w3.org/hg/webevents/raw-file/v1/touchevents.html#h_note_3):

"Some user agents implement an initTouchEvent method as part of the TouchEvent interface. When this method is available, scripts can use it to initialize the properties of a TouchEvent object, including its TouchList properties (which can be initialized with values returned from createTouchList). The initTouchEvent method is not yet standardized, but it may appear in some form in a future specification."

So still without any details of how such a method should look like.

In general adding more events for document.createEvent() but without dedicated initializer method (which are supported by browsers in the same way) is realy strange, especially if the trend is to remove (or limit) init*methods and use only constructors.

They were added because zcorpan reported usage of them in the bug associated with that change. I don't think that necessarily means we have to add corresponding init*Event() methods back. If they can stay gone, that's fine. If that means we try removing "messageevent" as argument again, fine. This part of the specification is still a bit experimental as it's only been a few years since we switched away from this model.

Is there any point to creating the event that way if it can't be initialised?

https://github.com/search?l=javascript&q=createevent+messageevent&ref=searchresults&type=Code 19,392
https://github.com/search?l=javascript&q=initmessageevent&ref=searchresults&type=Code 19,393

It seems to me that sites that use createEvent('messageevent') always also use initMessageEvent.

That makes more sense.

Checked in as WHATWG revision r8711.
Check-in comment: Add initMessageEvent()
http://html5.org/tools/web-apps-tracker?from=8710&to=8711

"in <span>MessagePort</span>[]? portsArg"

"in " has been obsolete for a long time.

"<span>MessagePort</span>[]" should become "sequence&lt;<span>MessagePort</span>>"

Checked in as WHATWG revision r8760.
Check-in comment: Fix IDL for initMessageEvent()
http://html5.org/tools/web-apps-tracker?from=8759&to=8760