W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2013

Re: Last Call comments

From: Scott González <scott.gonzalez@gmail.com>
Date: Wed, 10 Apr 2013 07:52:45 -0400
Message-ID: <CAO8i3idtkhuuefJPYAYwOp8qnY9Jbz+O9GsU=qo_ACP4ranwXA@mail.gmail.com>
To: Konstantinov Sergey <twirl@yandex-team.ru>
Cc: Rick Byers <rbyers@google.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On Wed, Apr 10, 2013 at 5:57 AM, Konstantinov Sergey

> 08.04.2013, 19:24, "Scott González" <scott.gonzalez@gmail.com>:
> > On Mon, Apr 8, 2013 at 11:06 AM, Konstantinov Sergey <
> twirl@yandex-team.ru> wrote:
> >> Okay, look at the hammer.js pointer code:
> https://github.com/EightMedia/hammer.js/blob/master/src/pointerevent.js
> >> 55 lines of code are just redundant and is used to handle the simpliest
> things: the number of touches and the positions of touches. And this code
> will be completely broken if some other script on the page uses the
> capturing.
> >
> > I think it's unfair to point to an abstraction over several event types
> when that's exactly what Pointer Events is. If Hammer.js was coding over
> the Pointer Events API and mapping Touch Events to Pointer Events, the code
> would be very different.
> Whether you map Touch Events to Pointer or Pointer to Touch, or event if
> you write code for PointerEvents alone - you have to count the pointers, to
> separate single-input from multi-input and to obtain the positions
> pointers. I could hardly imagine the application which need to work with
> pointers and doesn't need to do such things.

In my opinion, this is a non-issue. We've already agreed to add an API for
getting the full list of active pointers in v2. I'm sure I could write this
in less than 55 LOC with v1. See Rick's email from yesterday [1], which
mentions an easy way to create "frames".

I'm not even sure why this is relevant to pointer capture. Capturing to a
specific element doesn't stop bubbling and it doesn't fake the x/y
coordinates, so you've really lost nothing in terms of detecting gestures.

So these 55 lines of code (usually more - you usually need to dispatch the
> event streams because generally working with single-input and working with
> multi-input are completely different tasks which are solved by different
> modules) is an additional problem that PointerEvents add to developer
> because the spec doesn't bother about basic developer needs.

It seems like you feel that gestures are a basic need that should be
directly addressed by Pointer Events. Is that the case?

Received on Wednesday, 10 April 2013 11:53:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC