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 12:39:15 +0400
To: Scott González <scott.gonzalez@gmail.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-Id: <2861365496755@webcorp1e.yandex-team.ru>
Okay, actual scenario. Test page: http://konstantinov.cc/case.html
There is the map and the marker on top of it. You may drag the map through the marker; you may open the info window on the marker by clicking it.

The common way to produce such a behavior is:
1) marker listens "down", "move" and "up" events on itself (touchstart, touchmove, touchend in Safari Mobile; pointerdown, pointermove, pointerup in IE10); the "click" detection algorithm is simple: (a) there was less movement than 5px (tremor detection), (b) "down" and "up" targets are the same.
2) map listens "down", "move" and "up" events and starts dragging when movement becomes more than 5px.

If we use the standard "document.addEventListener-with-capturing" method for handling "move" and "up" events, there is no problem. Two separate behaviors don't conflict and perfectly work simultaneously.

But let us use "setPointerCapture" instead. Then map (as a parentNode for the marker) will place capturing on itself and "up" event target property will be set to map element. So "click" detection fails and popup window never shows.

The capturing effectively breaks the possibility for these two perfectly independent scenarios to work together. Okay, we control these scenarios, but what if one of them is provided by the other script (framework, plugin, etc) on page? For example, the map is placed in the draggable container itself and our dragging mechanism is disabled - then we cannot open the info window because of the user script's capturing.

This example demonstrates the possible problems even if the world is ideal; but the world is not ideal. There are many frameworks and plugins that do bad things; for example, old Prototype and Mootools alter Array.prototype.shift and Array.prototype.forEach and break our API, so our technical support has to deal with user scripts finding the code, which breaks our map.

PointerEvents will provide lots of possibilities to write slightly incorrect script to break our map behavior. So PointerEvents will cost us time and money to deal with such script. For what? What are those "essential cases" which cannot be solved using standard DOM functionality?

08.04.2013, 19:45, "Scott González" <scott.gonzalez@gmail.com>:
> On Mon, Apr 8, 2013 at 11:35 AM, Konstantinov Sergey <twirl@yandex-team.ru> wrote:
>>>>> We should try to address the deadlock.
>>>>
>>>> How?
>>>
>>> I don't know. It's something we should discuss.
>>>
>>> Perhaps the first call always wins and there is a flag to indicate whether the pointer is captured. We'd need to talk through various scenarios and determine what makes sense.
>>
>> And what about encapsulation? Why my script needs to check if some other script on the page are doing something with capturing? And how do I make a decision whether to take the capturing away or not?
>
> Again, can you provide actual scenarios for us to evaluate?

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

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