Re: Last Call comments

Why would you want to capture the pointer before you know if you should? You 
won't have any problem if you refrain from capturing the pointer on the map 
as long as the drag gesture didn't start.

It's not because you're using a feature the wrong way that the feature 
itself is wrong... The capture system does exactly what it is expected to 
do: it says a pointer has been captured by an element and therefore should 
not interact with the other elements. As long as you didn't start your 
gesture, the pointer isn't tied to any element and should not be captured.

-----Message d'origine----- 
From: Konstantinov Sergey
Sent: Tuesday, April 09, 2013 10:39 AM
To: Scott González
Subject: Re: Last Call comments

Okay, actual scenario. Test page:
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 
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" <>:
> On Mon, Apr 8, 2013 at 11:35 AM, Konstantinov Sergey 
> <> 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

Received on Tuesday, 9 April 2013 09:02:05 UTC