DOM events: differences between "interface" names and "feature" names
Reported by Diego Perini | March 26th, 2010 @ 02:51 AM
I believe all event interfaces does not end with the letter "s", seems to me those are features names. It is "MouseEvent" and not "MouseEvents", "Event" and not "Events". Though some browser accepts both syntaxes for some of them, but only the first is the correct one as for specifications.
document.createEvent("Event");
document.implementation.hasFeature("Events", "");
document.createEvent("MouseEvent");
document.implementation.hasFeature("MouseEvents", "");
Thank you for the great work and the details you have put in it.
Comments and changes to this ticket
-
nickg March 26th, 2010 @ 09:56 AM
I believe the plural is odd but correct
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-document
As an example, a user wishing to synthesize some kind of UIEvent would call createEvent with the parameter "UIEvents".
To create an instance of the MutationEvent interface, use the feature string "MutationEvents"
Note: To create an instance of the Event interface for the HTML event module, use the feature string "HTMLEvents" as the value of the input parameter used with the createEvent method of the DocumentEvent interface.
etc. By feature string, they mean the input into createEvent
Which browser support the singular version?
-
nickg March 26th, 2010 @ 11:33 AM
ahh thanks for the update. I looked for DOM3 Events, but didn't find it at first blush.
Let me re-read. It will be a snap to fix/update either way!
--nickg
-
nickg March 27th, 2010 @ 04:01 AM
- State changed from new to resolved
- Assigned user changed from Thatcher to nickg
Ok, cleaned it up even more. It's all data-driven now. You can add types (or delete them) on your own without making a patch.
http://github.com/thatcher/env-js/commit/fba4c12d18728ce6bc525fbd45...
Can you make a separate bug for your documentation request (just cut-n-paste those last paragraphs into a new ticket?) thanks!
--nickg
-
Steven Parkes March 27th, 2010 @ 05:01 AM
Touch events make as much sense as mouse events. A headless browser has no less of a touch interface than it does of a mouse interface.
I'll end up doing this at some point ... unless someone else gets to it first :)
-
nickg March 27th, 2010 @ 07:01 AM
@diego -- given my task list, I probably won't get around to writing them, but you can! Patches very welcome for additional event types! Let me know if you need help getting started.
-
nickg March 31st, 2010 @ 02:49 AM
Hi. To help me understand your needs, what you use touchevent for. A
simple stub would be easy, but not sure if it is enough -
Steven Parkes March 31st, 2010 @ 05:19 AM
I brought up touch events. At the base level, it's just a matter of creating the necessary event types and having the right fields.
How to use them is a more open issue, as are all the events that include screen coordinates. It's still an open issue in my mind that, at least for me, I'll get to as I start doing TDD for touch applications.
Lots of interesting little things ... there'a weird hierarchy of touch events vs mouse/click events vs. gesture events (zoom/rotate). Not really sure what the value/effort ratio is going to turn out on this. At the same time, manual testing is expensive.
So it'll be an interesting adventure.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
a javascript browser environment