1182609 - Consider adding UIEvent.sourceCapabilities

Status: NEW

(Core :: DOM: Events, enhancement)

Description

[Rick Byers]

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.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

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

[Olli Pettay [:smaug][[e-mail]]]

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

[Olli Pettay [:smaug][[e-mail]]]

See also
https://github.com/RByers/InputDevice/issues/19

Comment 4

[Rick Byers]

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

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 6

[Rick Byers]

We've updated the naming to InputDeviceCapabilities and UIEvent.sourceCapabilities based on Olli's feedback (thanks!).

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

And I think that way adding the property to UIEvent makes more sense even if the object has just one capability initially.