146848 2015-07-10 12:31:48 -0700 Consider implementing UIEvent.sourceCapabilities 2024-02-01 04:45:21 -0800 1 1 1 Unclassified WebKit DOM WebKit Nightly Build All All NEW https://bugs.webkit.org/show_bug.cgi?id=210054 http://wicg.github.io/InputDeviceCapabilities/ P2 Normal --- 1 rbyers webkit-unassigned ahmad.saleem792 annevk a_protyasha ap benjamin contact dino rniwa sam tdresser webkit wenson_hsieh oldest_to_newest 1108713 0 rbyers 2015-07-10 12:31:48 -0700 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. 1108830 1 sam 2015-07-10 17:59:48 -0700 Seams reasonable. What working group is this work slated for? 1108864 2 rbyers 2015-07-10 20:00:09 -0700 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). 1108899 3 ap 2015-07-10 23:10:09 -0700 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. 1108919 4 rbyers 2015-07-11 03:32:24 -0700 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. 1503158 5 lforschler 2019-02-06 09:18:23 -0800 Mass move bugs into the DOM component. 1622944 6 contact 2020-02-26 02:26:14 -0800 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. 2009695 7 ahmad.saleem792 2024-02-01 04:43:47 -0800 I can't find any WPT tests and also any Mozilla Position for this API. Although, if I look into UI_Event.idl file in Chromium / Blink source, I can find it. Anything to do here?