This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Concrete proposal: http://rbyers.github.io/InputDevice/inputdevice.html There's been a bit of support on www-dom for this (including from Gary): https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0120.html, but not much discussion. We're pretty close to doing an intent-to-ship for blink on this, so it would be great if we could decide whether there is interest in adding this to UI Events (or possibly some other spec). If there's interest, I'm happy to create a pull request.
We've discussed this scenario a few times in the Touch Events and Pointer Events groups. It seems useful to a certain set of folks. I don't have any initial concerns with your spec proposal. Most of my questions stem from the roadmap for this feature beyond just firesTouchEvents. Do you have any consumers of the polyfill that are helping validate this satisfies their needs? Given we're creating a new interface here for this rather than a single property, I'd love to know if you have a scope in mind for what other types of information might eventually get added to SourceDevice (is it input characteristic properties, such as discussed in [1], or just info about how the events/model will be processed like firesTouchEvents; should we also have a firesPointerEvents property?). Given it seems set up intentionally for more members than just the one in the spec today and given UI Events is fairly far along as a spec, I think this makes more sense as a standalone spec in the new Incubator Community Group. [1]https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0121.html
(In reply to Jacob Rossi [MSFT] from comment #1) > We've discussed this scenario a few times in the Touch Events and Pointer > Events groups. It seems useful to a certain set of folks. I don't have any > initial concerns with your spec proposal. Most of my questions stem from the > roadmap for this feature beyond just firesTouchEvents. Do you have any > consumers of the polyfill that are helping validate this satisfies their > needs? Not directly, no. I've been working with the Google+ team, but they long ago wrote a library that behaves like my polyfill does and (after struggling with various hacks to this problem for years) they're now happy with it and so have little reason to switch to a different polyfill. They've reviewed the spec though and have expressed their support for it. > Given we're creating a new interface here for this rather than a single > property, I'd love to know if you have a scope in mind for what other types > of information might eventually get added to SourceDevice (is it input > characteristic properties, such as discussed in [1], or just info about how > the events/model will be processed like firesTouchEvents; should we also > have a firesPointerEvents property?). The former. Eg. I could certainly imagine 'supportsTilt', 'maxContactPoints' etc. properties, as well as possibly an API to enumerate all the input devices in the system (i.e. it's about exposing the state of the system, not some event-context-dependent thing). To me this is the future for PointerEvent.pointerType that we've discussed a few times (eg. if some 4th pointer type comes along - will we really be able to add another pointer type string while still being compatible with existing code?). This brainstorming doc [2] is the outcome of the www-dom thread about what a possible future for this API might look like. [2] https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit# > Given it seems set up intentionally for more members than just the one in > the spec today and given UI Events is fairly far along as a spec, I think > this makes more sense as a standalone spec in the new Incubator Community > Group. SGTM. Discourse thread started here: http://discourse.wicg.io/t/inputdevice-api-for-identifying-mouse-events-derived-from-touch/972/1. I'm happy to call this bug 'WONTFIX' if others agree. I know Gary wanted to use this API for some keyboard scenarios, so perhaps he should weigh in on what he sees the right next steps to standardization being. > [1]https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0121.html
Now tracking as: https://github.com/w3c/uievents/issues/49