Bug 146848 – Consider implementing UIEvent.sourceCapabilities

• Status: NEW
• Component: DOM

[Rick Byers]

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.

[Sam Weinig]

Seams reasonable. What working group is this work slated for?

[Rick Byers]

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).

[Alexey Proskuryakov]

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.

[Rick Byers]

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.

[Lucas Forschler]

Mass move bugs into the DOM component.

[Ben Frain]

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.

[Ahmad Saleem]

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?