|Summary:||Consider implementing UIEvent.sourceCapabilities|
|Product:||WebKit||Reporter:||Rick Byers <rbyers>|
|Severity:||Normal||CC:||ap, benjamin, contact, dino, rniwa, sam, tdresser, webkit|
|Version:||WebKit Nightly Build|
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.