So we should only have these:

* CustomEvent	
* Event
* Events
* HTMLEvents
* MouseEvent
* MouseEvents
* UIEvent
* UIEvents

Right?

I.e. we won't add CustomEvents or HTMLEvent.

Looks correct to me.

It is not clear to me that this list is extensible by other specs.

The idea is for it to not be extensible. I realize we may have to add more names, it's currently conservative.

FWIW here are the current test results for this:

http://w3c.github.io/dom/test-results/all.html#test-file-50

What is wrong with the current spec which says case-insensitive comparison.


Engines allow trailing 's' on some old interface names.

(In reply to Olli Pettay from comment #5)
> What is wrong with the current spec which says case-insensitive comparison.

I was hoping we could remove this quirks to make things simpler since it is very unlikely that any web content depends on this.

> Engines allow trailing 's' on some old interface names.

We still need to allow that.

In webdevdata data set 2013-09-01 102,000 pages I see the following instances that don't match those in comment 1 (there were 616 createEvents in total):

"TouchEvent"
'KeyEvents'
"TouchEvent"
'MessageEvent'
"TouchEvent"
'TouchEvent'
"TouchEvent"
"TouchEvent"
"TouchEvent"
"TouchEvent"
"TouchEvent"

So from this data it seems it doesn't need to be case-insensitive, but possibly some values should be added (TouchEvent?).

$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -E "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" >> ../createEvent.txt
$ grep -Ec "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" createEvent.txt
616
$ grep -Ev "\.createEvent\s*\(\s*[\"'](CustomEvent|Event|Events|HTMLEvents|MouseEvent|MouseEvents|UIEvent|UIEvents)[\"']" createEvent.txt > other-createEvent.txt

(In reply to Simon Pieters from comment #7)
> In webdevdata data set 2013-09-01 102,000 pages I see the following
> instances that don't match those in comment 1 (there were 616 createEvents
> in total):
> 
> "TouchEvent"
> 'KeyEvents'
> "TouchEvent"
> 'MessageEvent'
> "TouchEvent"
> 'TouchEvent'
> "TouchEvent"
> "TouchEvent"
> "TouchEvent"
> "TouchEvent"
> "TouchEvent"
> 
> So from this data it seems it doesn't need to be case-insensitive, but
> possibly some values should be added (TouchEvent?).
> 
> $ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -E
> "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" >> ../createEvent.txt
> $ grep -Ec "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" createEvent.txt
> 616
> $ grep -Ev
> "\.
> createEvent\s*\(\s*[\"'](CustomEvent|Event|Events|HTMLEvents|MouseEvent|Mouse
> Events|UIEvent|UIEvents)[\"']" createEvent.txt > other-createEvent.txt

I have also seen examples that refer to "KeyboardEvent":

https://developer.mozilla.org/en-US/docs/Web/API/event.initKeyEvent

Not sure how many websites out there use it though.

Also I wonder why there are tests to verify that createEvent("ProgressEvent") is not possible? Is it special and needs as test compared to the above?

We should probably have tests for all event interfaces that are not supported in the legacy createEvent() API. Having one for ProgressEvent seems like a good start.

(In reply to Anne from comment #9)
> We should probably have tests for all event interfaces that are not
> supported in the legacy createEvent() API. Having one for ProgressEvent
> seems like a good start.

I was just surprised that ProgressEvent has its own test:
http://www.w3c-test.org/dom/events/ProgressEvent.html

It seems to me writing a test for every possible event interface out there is not practical, unless there is whitelisting.

Well we know all the event interfaces in the platform. And they do all need tests. Adding a line for whether or not it should work through the createEvent() API does not seem like a big deal.

(In reply to Erik Arvidsson from comment #0)
> Blink/WebKit do not supports lowercase names for the interface argument.
> 
> http://dom.spec.whatwg.org/#dom-document-createevent
> 
> It therefore seems like the open web cannot depend on this and therefore we
> should be able to clean up the spec a bit.
> 
> Notice that engines all allow a trailing 's' on the interface name.

IE _does_ support all lowercase names. For example:
  document.createEvent("mouseevent") 
gives you an instance of the MouseEvent constructor. 

Is "clean up the spec" really the motivation for this?

Even if the spec was tightened up to not allow this, I'm not sure it really matters enough to risk any compatibility impact to change our implementation in the near future.

(In reply to Travis Leithead [MSFT] from comment #12)
> Even if the spec was tightened up to not allow this, I'm not sure it really
> matters enough to risk any compatibility impact to change our implementation
> in the near future.
I could say the same about Gecko.

Fair, ASCII case-insensitive does not seem too bad given that the list of names is restricted and its a legacy API anyway.

Fair enough.