RE: Moving InputDeviceCapabilities spec to WICG?

We support moving this to WICG. I'm not very convinced the firesTouchEvents capability is really going to be used much, but for the few it will be useful (which probably means this is a low pri for Ted’s team to implement). However, I’m interested in exploring via this spec exposing pointer/hover capabilities like those that exist in media queries.

-Jacob


From: Rick Byers<mailto:rbyers@chromium.org>
Sent: Tuesday, November 24, 2015 10:09 AM
To: smaug<mailto:smaug@welho.com>; Jacob Rossi<mailto:Jacob.Rossi@microsoft.com>
Cc: Chris Wilson<mailto:cwilso@google.com>; public-wicg@w3.org<mailto:public-wicg@w3.org>
Subject: Moving InputDeviceCapabilities spec to WICG?

Hey Olli / Jacob,
I think you two had the most input on the InputDeviceCapabilities spec<http://rbyers.github.io/InputDevice/index.html> design from the Mozilla / Edge perspective.  It sounds to me like we should probably officially move this spec into the WICG (instead of just hanging off my personal GitHub with discussions from various w3c lists / meeting notes).  Any thoughts?  Any thoughts on possible future implementations in your engines?

Thanks,
   Rick

---------- Forwarded message ----------
From: Rick Byers <rbyers@chromium.org<mailto:rbyers@chromium.org>>
Date: Fri, Aug 14, 2015 at 12:23 PM
Subject: Re: Intent to Ship: UIEvent.sourceCapabilities & InputDeviceCapabilities.firesTouchEvents
To: blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>>
Cc: Timothy Dresser <tdresser@chromium.org<mailto:tdresser@chromium.org>>, "lanwei@chromium.org<mailto:lanwei@chromium.org>" <lanwei@chromium.org<mailto:lanwei@chromium.org>>

[Replying to the thread with the correct subject using @chromium.org<http://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<https://lists.w3.org/Archives/Public/www-dom/2014JulSep/0100.html> 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<https://docs.google.com/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#heading=h.rbcct8al2kop>.  Through that process we were asked to propose a more general API which could be used<https://docs.google.com/a/chromium.org/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit?usp=drive_web> 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<https://bugzilla.mozilla.org/show_bug.cgi?id=1182609#c2>).  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<https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#heading=h.o7qaw089pyqp>, 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<https://www.w3.org/community/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<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/p1sy9aQDmtU> obviously followed the same pattern, and I can guarantee this won't be the last intent-to-ship from input-dev of this style ;-)

On Fri, Aug 14, 2015 at 12:20 PM, Lan Wei <lanwei@google.com<mailto:lanwei@google.com>> wrote:

Contact emails

rbyers@chromium.org<mailto:rbyers@chromium.org>, tdresser@chromium.org<mailto:tdresser@chromium.org>, lanwei@chromium.org<mailto:lanwei@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 the InputDeviceCapabilities API is currently too limited to be exposed to the web.<https://bugzilla.mozilla.org/show_bug.cgi?id=1182609>


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 implement more 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