Re: Call for participation: Online meeting on Gesture Events Standard in Web

On Tue, May 22, 2018 at 4:29 PM Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 22/05/2018 21:12, Rick Byers wrote:
> [...]
> > 2) There's (almost*) nothing that a built-in browser API could do here
> > that a great JavaScript library couldn't. So the value of a W3C spec and
> > built-in browser implementations isn't that high compared to the
> > alternative of one widely adopted high-quality gesture library.
>
> The one area that I could see benefitting here is that, with a
> browser-native API, there's a possibility for developers to listen for
> the high-level events, AND for the browser to then also provide
> alternative ways of triggering those - think for instance some built-in
> pinch-zoom or swipe that can be triggered purely through the
> keyboard/when using assistive technologies/etc. Basically, the
> undelivered promise of IndieUI events https://www.w3.org/WAI/IndieUI/


+1.  If there's a credible plan to improve accessibility here, then that
would be a strong reason IMHO.  Aren't assistive technologies basically
already forced to emulate  low level input though?  Can we reasonably
expect that to EVER change, given that there will always be some
non-trivial fraction of sites using the low-level input APIs?


> > So personally I'd expect focusing on building and driving adoption of a
> > high-quality library/polyfill to be much higher impact (for the laudable
> > goal of "merging web and mobile apps") than investing in a specification
> > or browser implementations.
> >
> > Though if we were to do that, perhaps the fasted path to broad adoption
> > would be to focus on the existing gesture API shipped by Safari?  If
> > there was a spec for this API, broad adoption of the API (via polyfill
> > and/or native Safari-only API), and at least one other engine (Gecko?)
> > interested in implementing it then I wouldn't be surprised to see
> > implementation interest from chromium as well (as for touch events in
> > the first place).  In comparison, getting broad adoption for an entirely
> > new API like the one proposed here seems much harder to me...
>
> I'm actually wondering if the Safari gesture API used at all by
> developers in the wild. It's also very limited in what it offers. Then
> again, Microsoft's much more beefy and complex MSGesture API is likely
> also not used in the wild, except perhaps on MS-specific platforms (UWP
> applications and similar).
>

Yeah, it's a good question.  A quick search using nerdydata.com suggests
that gesturestart is used by perhaps 50% of the top site that pointerdown
is used by, which in turn is used by only 10% of the top sites that
touchstart is.  We could get more data from HTTP Archive.

Speaking of polyfills/libraries, Hammer.js had, at least for a while, a
> good amount of positive industry nods (but I haven't followed it for
> ages, and I think it's mostly stagnant at this point).
>

Yeah my argument back in 2013 is that we should all invest more in making
hammer.js great  in particular.... Of course I never actually devoted much
time to that myself ;-)


> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>