- From: Konstantinov Sergey <twirl@yandex-team.ru>
- Date: Tue, 09 Apr 2013 13:06:18 +0400
- To: François REMY <francois.remy.dev@outlook.com>, Scott González <scott.gonzalez@gmail.com>
- Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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. 09.04.2013, 13:01, "François REMY" <francois.remy.dev@outlook.com>: > 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 > Cc: public-pointer-events@w3.org > Subject: Re: Last Call comments > > 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/ -- Konstantinov Sergey Yandex Maps API Development Team Lead http://api.yandex.com/maps/
Received on Tuesday, 9 April 2013 09:06:47 UTC