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: Tue, 09 Apr 2013 14:47:22 +0400
To: François REMY <francois.remy.dev@outlook.com>
Cc: Pointer Events WG <public-pointer-events@w3.org>
Message-Id: <9001365504442@webcorp1e.yandex-team.ru>
09.04.2013, 14:25, "François REMY" <francois.remy.dev@outlook.com>:
>>  Sorry, nothing wrong.
>>  Map catches the pointerdown event and immediately sets the capture, because next pointermove event may already be out of the map element if user places the finger near the map edge. There may be not dragging, but some flick gesture where the situation when second event occurs outside of target element is common.
>
> This has a probability of happening close to zero. When an user want to drag, it will never start near the end of the map close to the direction in which it want to drag to, it will start near the opposite edge or in the center, leaving plenty of free space in the direction of the flick. But, okay, let's say you want to solve even this use case.
>

No, it's definitely not. In first, there are many cases with "active edges" and other similar functionality when it's very common case when second event occurs on the other element. In second, different devices sends "move" event with different frequency depending on screen sensibility, and second event may be very distant from first.

> I have had no problem using setPointerCapture and solving your marker/map issue, as can be seen here:

I have no problem in solving this case two; what really troubles me is the situation when we have no control over whole system. The dragging behavior can be easily produced by some user framework, and then we have no ways to produce desirable behavior from our side. How do we solve such a case, when container dragging is implemented by user?

>
> I think you try too hard to remove a useful feature when it's used correctly.

My argument is not about the usability of these feature; I perfectly understand its benefits.
My concern is the lots of possibilities to use this feature incorrectly; this feature really works only when you are fully control your page and every single script on it. But this situation are vary rare in the modern web. Since the spec doesn't provide any mechanism for handling collisions, it is unsuitable for modern web.

> You're just too used to your 'hook on the document' trick and you fail to notice it's not needed in a world where you can simply use pointer capture. Hooking events on the document is a bad idea and will not work properly in the case your map is included in an IFRAME, something which I believe has more chance to happen than the tricky slide from the edge you were afraid of.

And how the capturing solves the iframe problem?
The main advantage of document capturing is its complete transprency. You cannot break any other script on page using document capruting.

>
> Anyway, have a look at my code (sorry, I cooked it very quickly, the quality may not be perfect but I tried to put enough comments to make it easy to understand).
>
> Best regards,
> François
>
> ________________
> PS: To be efficient, one should probably prevent the 'pointerdown' event to bubble to the ancestors of the map, because any gesture at an higher level than the map should never be triggered once the drag gesture did start.

That will be event worse. I could easily imagine lots of behaviors that dwell on the same events and do not conflict - the drag/click/multitouch example is the simplest one.

-- 
Konstantinov Sergey
Yandex Maps API Development Team Lead
http://api.yandex.com/maps/
Received on Tuesday, 9 April 2013 10:47:56 UTC

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