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: Thu, 11 Apr 2013 19:48:44 +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: <38691365695324@webcorp2e.yandex-team.ru>
11.04.2013, 19:11, "Scott González" <scott.gonzalez@gmail.com>:
> On Wed, Apr 10, 2013 at 9:05 AM, Konstantinov Sergey <twirl@yandex-team.ru> wrote:
>> 10.04.2013, 16:50, "Scott González" <scott.gonzalez@gmail.com>: > 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?
>
> I honestly don't know how to respond to this. MSPointerEvent got a lot of praise. So now we should wait for 100% perfection before anybody else implements anything?
>

There is major difference between "spec isn't 100% perfect" and "spec forces the developers to write redundant code and dirty hacks". In its current state the spec forces the developers to write redundant code and dirty hacks.

>>> Who said anything about breaking back compatibility? What suggested change is a breaking change?
>>
>> Removing the requirement "pointerId = 1 for mouse device", for example.
>
> I believe this is one of the most controversial parts of the API. Perhaps we can revisit this again.
>

So when we revisit it, the backwards compatibility will be broken, isn't it?
Accepting the v1 spec will freeze the flaws of the spec. We won't be able to alter the capturing or to make "touch-action" property to work on inline elements  without breaking the backwards compatibility.

And, what bothers me most, we will have very small room for maneuvre in the future gestures proposal discussion because we will be unable to change the underlying pointer spec if needed.

>>> 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.
>
> Here's the basic idea:
>
> var events = [];
> [
> "pointerdown",
> "pointermove",
> "pointerup",
> "pointercancel"
> ].forEach(function( eventType ) {
> document.addEventListener( eventType, function( event ) {
> events.push( event );
> });
> });
> function coalesce() {
> if ( events.length ) {
> // Do actual coalescing of events
> console.log( events.length );
> events = [];
> }
> requestAnimationFrame( coalesce );
> }
> requestAnimationFrame( coalesce );

I still dont't understand how this code solves the capturing problem.

-- 
Konstantinov Sergey
Yandex Maps API Development Team Lead
http://api.yandex.com/maps/
Received on Thursday, 11 April 2013 15:49:17 UTC

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