Bug 146848

Summary: Consider implementing UIEvent.sourceCapabilities
Product: WebKit Reporter: Rick Byers <rbyers>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: ap, benjamin, contact, dino, rniwa, sam, tdresser, webkit
Priority: P2    
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
URL: http://wicg.github.io/InputDeviceCapabilities/

Description Rick Byers 2015-07-10 12:31:48 PDT
Concrete proposal here: https://github.com/RByers/InputDevice

We're close to doing an intent-to-ship for this in blink, so it would be great to get a better understanding of whether WebKit has any interest in this API or has any outstanding concerns before we ship it.
Comment 1 Sam Weinig 2015-07-10 17:59:48 PDT
Seams reasonable. What working group is this work slated for?
Comment 2 Rick Byers 2015-07-10 20:00:09 PDT
Thanks!  I've been talking with WebApps (on www-dom), one of the UI Events spec editors have expressed support (https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0117.html).  UI Events certainly seems like the right place.  But I haven't yet been able to get any further than that yet.  I suspect we won't block shipping on the politics here (but would, of course, block if there are unresolved technical concerns with the API).
Comment 3 Alexey Proskuryakov 2015-07-10 23:10:09 PDT
Thank you for filing the bug!

The spec appears to be mostly about touch/mouse events at this time, and it is also quite extensible for other event types. Do you have future extension directions in mind?

There is already a note alluding to complexities with keyboard events, and it seems likely that the complexities will grow as use cases and various virtual input devices are considered.
Comment 4 Rick Byers 2015-07-11 03:32:24 PDT
Yes, there has been some brainstorming in the community about how we might want to extend this over time.  Some ideas here: https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#.  But as you say, the details can get complex, so I figure it's best to iterate incrementally in a careful scenario-driven fashion rather than go nuts all at once.

My focus right now is to solve one particular long standing problem for devices with both a mouse and touchscreen (so not itself that interesting for WebKit).  But no one wants to make one-off hacks just for that, so we're trying to establish a reasonable device info pattern for the future.
Comment 5 Lucas Forschler 2019-02-06 09:18:23 PST
Mass move bugs into the DOM component.
Comment 6 Ben Frain 2020-02-26 02:26:14 PST
Any movement on this. 

Here's a use case: building a piece of UI. If it's a touch capable pointer, I want to expose some custom UI for text input. If it's a fine pointer I expose a standard input.

In Chrome I can use tabindex to capture focus on a wrapping element and then query that focus event's 'sourceCapabilities' to see whether 'firesTouchEvents' is true. The fork my code appropriately.

Unable to do this for Safari.