InputDevice API for identifying mouse events derived from touch

I’ve long seen developers struggle to identify whether a mousedown event is due to a real mouse, or as a result of touchscreen activity they’ve already handled via touchend. After more than a year of discussion in various W3C groups, I’ve come up with a generic InputDevice API that can solve this problem today while providing a clean path for addressing other similar issues in the future.

Any feedback? We’d like to ship a first version of this API in blink soon if possible, and others vendors have expressed some interest too.

Thanks, Rick

I have no real objections to this, but it seems to me the only place it would actually be useful is within polyfills (either FastClick or PEP), and those are still going to need to maintain the code path where this value isn’t present into the foreseeable future because of iOS, so I don’t really see its utility. If a content author wants to identify the source of an event, they should be coding against Pointer Events (with the Pointer Events Polyfill), not mouse events. I’d rather see work in Blink put toward native Pointer Events (and its supporting features like the touch-action CSS property) than a neither-here-nor-there solution that won’t be consistently available on the platforms that would need to expose it.

I guess we have to separate the immediate scenario (firesTouchEvents) from the longer term direction. Would you agree that there’s utility to the general notion of exposing additional device information in this way? This proposal has been designed in discussion with the Pointer Events Working Group, where we’ve long said we need a place to hang additional device information. In particular, we agreed to explore generalizations of navigator.maxTouchPoints and pointerType in a future version of the spec. By hanging a new API off of UIEvent we can get the same benefits for MouseEvent, TouchEvent and PointerEvent.

Regarding the foreseeable future for iOS, Apple has publicly indicated some support for adding this to WebKit, and I’ve had private discussions with Safari engineers that have influenced the design. Indeed one of my goals here is to provide a path for getting more device information available in an event-model-agnostic fashion so that the entire future of input on the web isn’t tightly coupled to Pointer Events which Apple is opposed to implementing.

Regarding the immediate-term issue of identifying mouse events derived from touch: Yes Pointer Events solves that, and we’re definitely actively implementing Pointer Events in blink (and I shipped touch-action over a year ago now). But the web evolves incrementally and I believe (given the lack of universal support for Pointer Events) that it’s best to provide incremental solutions for small problems to web developers that don’t force them to rewrite all of their event handling code. There’s not yet evidence that developers are willing to depend on the Pointer Events polyfill in large scale production, so I don’t think it’s practical to tell developers the only way to solve this problem properly is to switch to the pointer event API.