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>
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>
Cc: Timothy Dresser <tdresser@chromium.org>, "lanwei@chromium.org" <
lanwei@chromium.org>


[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
<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> wrote:

> Contact emails
>
> rbyers@chromium.org, *tdresser@chromium.org <tdresser@chromium.org>*,
> 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
>