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

Re: Last Call comments

From: Konstantinov Sergey <twirl@yandex-team.ru>
Date: Wed, 10 Apr 2013 17:05:14 +0400
To: Scott González <scott.gonzalez@gmail.com>
Cc: Rick Byers <rbyers@google.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-Id: <1851365599114@webcorp1e.yandex-team.ru>
10.04.2013, 16:50, "Scott González" <scott.gonzalez@gmail.com>:
> On Wed, Apr 10, 2013 at 8:40 AM, Konstantinov Sergey <twirl@yandex-team.ru> wrote:
>> 10.04.2013, 15:52, "Scott González" <scott.gonzalez@gmail.com>:
>>> On Wed, Apr 10, 2013 at 5:57 AM, Konstantinov Sergey <twirl@yandex-team.ru> wrote:
>>>> 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".
>>>
>>
>> Then I don't understand why to accept this v1 specifiation if it is (a) incomplete, (b) will be modified breaking back compatibility.
>
> We're not going to wait until we think a specification solves 100% of all problems before publishing. We need to be able to iterate. Otherwise, way too much time will pass before this is published.

Since we accept the spec, the browsers will start to implement it and the developers will start to write code having just the incomplete v1 spec. I don't see why this step - implement the spec - is needed. It's already implemented in IE10, why to force more browsers and more developers to deal with it?

>
> Who said anything about breaking back compatibility? What suggested change is a breaking change?

Removing the requirement "pointerId = 1 for mouse device", for example.

>>>> 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?
>>>
>>
>> Just the opposite. Our Safari Mobile code use the touch* events only. We don't need gestures (i.e. specific events to detect gestures) because we just need the positions of every touch. That's one of the most useful features of Safari Mobile touch event system in my opinion.
>>
>> But we failed to use the same approach in our IE10-specific code because it's very hard to use pointers without gestures. That's why I don't like the idea of discussing PointerEvents proposal alone leaving the gestures out of scope.
>
> The framing will be completely arbitrary for different devices. What's wrong with the suggested approach of using requestAnimationFrame()?

Sorry, don't understand about requestAnimationFrame.

-- 
Konstantinov Sergey
Yandex Maps API Development Team Lead
http://api.yandex.com/maps/
Received on Wednesday, 10 April 2013 13:05:46 UTC

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