Re: Moving InputDeviceCapabilities spec to WICG?

Sounds great, thanks!  I'd definitely support adding the hover/pointer
properties (though there has been some bikeshedding around how exactly it's
best to expose that).

Hopefully the developers that want firesTouchEvents will rely on a polyfil
<https://rbyers.github.io/InputDevice/inputdevicecapabilities-polyfill.js> for
other browsers, and we can use measurements of usage in the wild to gauge
interest.  We've been quiet about this API so far, but I'll start
encouraging its use (but it's fairly niche so I don't expect a ton either).

Rick

On Mon, Jan 4, 2016 at 1:06 PM, Ted Dinklocker <Ted.Dinklocker@microsoft.com
> wrote:

> I agree with Jacob and also switching over to my work email address…
>
>
>
> *From:* Jacob Rossi [mailto:Jacob.Rossi@microsoft.com]
> *Sent:* Monday, January 4, 2016 8:28 AM
> *To:* Rick Byers <rbyers@chromium.org>; smaug <smaug@welho.com>
> *Cc:* Chris Wilson <cwilso@google.com>; public-wicg@w3.org; Ted
> Dinklocker <ted@dinklocker.com>
> *Subject:* 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 <rbyers@chromium.org>
> *Sent: *Tuesday, November 24, 2015 10:09 AM
> *To: *smaug <smaug@welho.com>; Jacob Rossi <Jacob.Rossi@microsoft.com>
> *Cc: *Chris Wilson <cwilso@google.com>; 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>
> 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
> <https://www.chromestatus.com/features/5681847971348480>*
>
>
>
>
>
>
>