Consider adding UIEvent.sourceCapabilities

NEW
Unassigned

Status

()

Core
DOM: Events
--
enhancement
2 years ago
a year ago

People

(Reporter: Rick Byers, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2438.3 Safari/537.36

Steps to reproduce:

Concrete proposal here: https://github.com/RByers/InputDevice

Based, in part, in discussion with Olli Pettay and Matt Brubeck in the touch events community group.

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 Firefox is interested in this API or has any outstanding concerns.

Updated

2 years ago
Severity: normal → enhancement
Component: Untriaged → DOM: Events
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All

Comment 1

2 years ago
interface InputDevice {
    readonly    attribute boolean firesTouchEvents;
};
as such doesn't warrant adding a new interface. One could just add similarly behaving boolean attribute to UIEvent.

So we need InputDevice extended and used also in other specs.

Comment 2

2 years ago
But anyhow, I like the idea having some kind of InputDevice. It is just that the API is currently too limited, too draft-y to be exposed to the web, IMO.

Comment 3

2 years ago
See also
https://github.com/RByers/InputDevice/issues/19
(Reporter)

Comment 4

2 years ago
Thanks for your feedback Olli.

Adding a single boolean to UIEvent was my initial proposal nearly a year ago (https://lists.w3.org/Archives/Public/public-touchevents/2014Sep/0000.html) but was shot down in the touch events community group as being too special-purpose to justify adding to MouseEvent.  We discussed this in a TECG call back in Jan (you are listed as present but apparently didn't comment: https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0020.html) and agreed to focus on a more general purpose API with broader applicability than this single scenario.  I produced a longer-term API sketch as part of the discussion on www-dom (https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw) and got support on the general shape from one of the UI Events editors there (https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0117.html).

So it sounds like the main concern here then is that the API should have more capabilities before Firefox would be interested in shipping it.  That's not unreasonable, but I'm not sure we'll want to block shipping this in blink for that reason.  We've been trying to ship some solution to the 'identify mouse events derived from touch' problem for a year already, and generally prefer shipping in small incremental steps over big new APIs ourselves.

Comment 5

2 years ago
The issue is that if we then a bit later realize that the current InputDevice API approach isn't quite what we want, we end up breaking the API and create a new one.
So a bit more flesh on the bones would make sense for this API.

As of now I think the capabilities based approaches is more future proof.
(Reporter)

Comment 6

2 years ago
We've updated the naming to InputDeviceCapabilities and UIEvent.sourceCapabilities based on Olli's feedback (thanks!).
Summary: Consider adding UIEvent.sourceDevice → Consider adding UIEvent.sourceCapabilities

Comment 7

2 years ago
And I think that way adding the property to UIEvent makes more sense even if the object has just one capability initially.
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.