Intent to Ship: UIEvent.sourceCapabilities & InputDeviceCapabilities.firesTouchEvents

[Lan Wei]

Contact emails

rby...@chromium.org, tdre...@chromium.org, lan...@chromium.org

Spec

Rick Byers’ draft:

http://rbyers.github.io/InputDevice/

Summary

The InputDeviceCapabilities API provides capability details about the physical device responsible for generating an event. InputDeviceCapabilities.firesTouchEvents returns whether this device dispatches touch events. All UIEvents now have a sourceCapabilities attribute which returns the InputDeviceCapabilities associated with the physical device responsible for them.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/inpu$20tdevice/blink-dev/wjtZl9jpCpI/xC0JTRKgc9kJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://output.jsbin.com/cidaxasivi

Compatibility Risk

We’ve received some positive support from W3C, Webkit and IE - see bug reports:

[W3C DOM WG] https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0117.html

[WebKit] https://bugs.webkit.org/show_bug.cgi?id=146848

[IE] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28938

However, Mozilla think the InputDeviceCapabilities API is currently too limited to be exposed to the web.

The risk is relatively low: even though we are the first one to implement this and it lacks a formal W3C spec, other browser vendors have expressed support for it. The official standardization process here is slower than we'd like - we've bounced around between a number of groups and are now testing out the new WICG process.  But from our discussions with the relevant browser engineers and spec editors, this simple start to the API seems very non-controversial, and we believe it's now safe enough to ship in blink.   There are other risks here, we intend to implement more features in InputDeviceCapabilities, but have not received support right now. If we decide all other proposed InputDeviceCapabilities attributes are unnecessary, then this approach to determining which mouse events are derived from touch will be somewhat more complicated than necessary (however simpler special-purpose APIs were all rejected by the community as not being sufficiently general).

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=476530

Entry on the feature dashboard

https://www.chromestatus.com/features/5681847971348480

[Rick Byers]

[Replying to the thread with the correct subject using @chromium.org addresses - sorry for the spam, please ignore the other thread]

Again I'll avoid weighing in officially on this one due to the conflict of interest :-).  But I wanted to provide a little more context on why I think it's time to ship this, despite the continuing lack of an official W3C spec.

A little over a year ago we started serious discussions on the www-dom and public-touchevents lists on how best to address the developer complaint we keep hearing that they can't reliably differentiate real mouse events from those synthesized in response to tapping a touchscreen.  Through that process we were asked to propose a more general API which could be used to address other similar issues and use cases in the future.  We have support in a number of forums for the big picture design here (including from Mozilla).  The main outstanding debate is whether this API is rich and important enough now to justify adding to the web, or whether we should wait until we have more concrete properties added to InputDeviceCapabilities.

I agree that there is some risk we could ship this and then never add anything more to InputDeviceCapabilities (leaving it looking a little silly), or decide we want a different name/structure for the next thing we add.  But given the brainstorming that's been done, I believe this risk is small.

I also personally believe that the web suffers from a lack of agility in responding to developer pain points which could be addressed by tiny low-risk APIs.  I started hearing concerns about this problem from developers over 4 years ago (when Chrome first started supporting touchscreen laptops), and have been actively working in the community to address it for the past year.  In retrospect I feel we've failed web developers already by taking so long to address what, would on other platforms, be addressed quickly with a tiny fix.  I'm hopeful that the new WICG will help enable a more incremental and efficient approach to platform micro-evolution (for the small stuff).

So I believe the next step here is to ship the best API we've been able to come to with a year of active debate in the web standards community, and then rely on developer interest to help move the API through the official standards process and implementations in other browsers. 

In addition to this specific intent, I'd love to see discussion on this general approach to incremental platform tweaks.  Scroll restoration obviously followed the same pattern, and I can guarantee this won't be the last intent-to-ship from input-dev of this style ;-)

[smaug]

On 08/14/2015 07:20 PM, 'Lan Wei' via blink-dev wrote:
> Contact emails
>
> rby...@chromium.org <mailto:rby...@chromium.org>, _tdre...@chromium.org <mailto:tdre...@chromium.org>_, lan...@chromium.org <mailto:lan...@chromium.org>
>
>
> Spec
>
> Rick Byers’ draft:
>
> http://rbyers.github.io/InputDevice/ <http://rbyers.github.io/InputDevice/index.html>

>
>
> Summary
>
> The InputDeviceCapabilities API provides capability details about the physical device responsible for generating an event.
> InputDeviceCapabilities.firesTouchEvents returns whether this device dispatches touch events. All UIEvents now have a sourceCapabilities attribute
> which returns the InputDeviceCapabilities associated with the physical device responsible for them.
>
>
> Link to “Intent to Implement” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/inpu$20tdevice/blink-dev/wjtZl9jpCpI/xC0JTRKgc9kJ
>
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
>
> Demo link
>
> https://output.jsbin.com/cidaxasivi
>
>
> Compatibility Risk
>
> We’ve received some positive support from W3C, Webkit and IE - see bug reports:
>
> [W3C DOM WG] https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0117.html
>
> [WebKit] https://bugs.webkit.org/show_bug.cgi?id=146848
>
> [IE] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28938
>

> However, Mozilla think theInputDeviceCapabilities API is currently too limited to be exposed to the web.
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1182609>
FYI, that bug is about the previous InputDevice API, not InputDeviceCapabilities API.

>
>
> The risk is relatively low: even though we are the first one to implement this and it lacks a formal W3C spec, other browser vendors have expressed
> support for it. The official standardization process here is slower than we'd like - we've bounced around between a number of groups and are now

> testing out the new WICG process <http://discourse.wicg.io/t/inputdevice-api-for-identifying-mouse-events-derived-from-touch/972>. But from our

> discussions with the relevant browser engineers and spec editors, this simple start to the API seems very non-controversial, and we believe it's now
> safe enough to ship in blink. There are other risks here, we intend to implementmore features

> <https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#heading=h.ci5c3zqsg9rp>in InputDeviceCapabilities, but have not

> received support right now. If we decide all other proposed InputDeviceCapabilities attributes are unnecessary, then this approach to determining
> which mouse events are derived from touch will be somewhat more complicated than necessary (however simpler special-purpose APIs were all rejected by
> the community as not being sufficiently general).
>
>
> OWP launch tracking bug
>
> https://code.google.com/p/chromium/issues/detail?id=476530
>
>

> Entry on the feature dashboard <http://www.chromestatus.com/>
>
> https://www.chromestatus.com/features/5681847971348480
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

[Rick Byers]

Thanks for the clarification!

So do you still feel it's too early to ship InputDeviceCapabilities, or in your opinion, is it OK if blink ships it now?

[Dimitri Glazkov]

LGTM1. The API surface seems small enough.

:DG<

[p...@google.com]

LGTM, give users the powah.

This seems reasonably extensible for future input events all browsers would be interested in supporting.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.