Most UIEvents at this point have a DOM Event constructor. TouchEvent is a notable exception. It's not a big use case, but JS-generated events are sometimes useful and (IMHO) ideally all event types would be consistent in this regard. Is there any interest in adding constructors to WebKit? Should be trivial.
We (Touch Event Community Group) have recently added constructor definitions to the draft TouchEvents level 2 spec: http://w3c.github.io/touch-events/touchevents.html#touchevent-interface (bug: https://github.com/w3c/touch-events/issues/10). Any feedback on the design? I'm happy to make changes before pages start depending on the API.
http://crbug.com/508675 tracks shipping these in blink.
Beth, is this little tweak something you hope to do at some point?
(In reply to comment #1)
> Beth, is this little tweak something you hope to do at some point?
Thanks for cc'ing me! Could be interesting. :-)
/cc grouts who seems to be doing other TouchEvents works (yay!)
I am working on the TouchEvent constructor.
Added a TouchEvent constructor via Bug 158883. It looks like WebKit on iOS already has a constructor for Touch so closing.
Chris, does the Touch constructor on iOS follow the spec (and normal DOM constructor pattern) in taking a dictionary? foolip@ says he can only get it working by passing a list of parameters similar to createTouch.
(In reply to comment #7)
> Chris, does the Touch constructor on iOS follow the spec (and normal DOM
> constructor pattern) in taking a dictionary? foolip@ says he can only get
> it working by passing a list of parameters similar to createTouch.
It does not look like we support passing a Dictionary at the moment, it takes in a list of parameters :/
> It does not look like we support passing a Dictionary at the moment, it takes in a list of parameters :/
Ugh, yeah that's not going to be interoperable (the whole point of the constructors is to avoid having to keep extending a long argument list).
Ok if we reopen this to track getting WebKit passing this test?
Note that if issue 157269 isn't going to be fixed, than the Safari-specific TouchEvent constructor should probably also have a way to set these non-standard properties on TouchEvent.
I have now come across one script that is relying on these properties on Safari: http://s0.2mdn.net/instream/video/client.js, and as a result other libraries cannot move from initTouchEvent to the TouchEvent constructor without breaking this script.
Darn sorry, used the wrong hotword. See "bug 15726" for the clientX/clientY issue above.
Damn damn, not my day :-)
See "bug 157269" for the clientX/clientY issue above.
Resolved in sub-bugs.