Re: Last Call comments

09.04.2013, 15:02, "Fran├žois REMY" <>:
>>>  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?
> Exactly the way I did: you set the pointer capture tentatively during the tunneling phase: if a child (in this case: the marker) want the capture, it can still get it and I (the map) will continue to be notified by the events because I know the event do bubble.

That doesn't solve any problem. And what if map should respond to tap and marker - to the drag? We can't detect whether the user script works up or down the dom tree.

> If my case, I went further and made sure the pointer capture was being reset at every stage (pointermove) of the gesture, because it allow the map to get the direct capture when the marker detects it cannot handle the gesture.
>>  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.
> I don't think there are so much. The only thing you can get wrong is the order in which you set the captures. If you setup a standard (like: setup captures in the tunneling phase like I did), you're completely safe.
>>  And how the capturing solves the iframe problem?
> When a pointer is captured, the events continue to fire even if the pointer moves outside the current document, and even outside the current window (on IE/Windows). So, I can continue to drag my map outside the current window, and therefore also outside the current iframe.

Which paragraph of the spec defines such a behavior?

>>  The main advantage of document capturing is its complete transprency. You cannot break any other script on page using document capruting.
> That's completely false. You can get very weird behavior on the document because of stopImmediatePropagation because then the order in which the events are registered start to matter, and you've no way to control that if you don't control every script.

I can hardly see the "essential cases" where stopImmediatePropagation should be called on document. There is no practical use and no code examples over the web.
And setPointerCapture is the recommended way to deal with pointer events and there are many examples of using it, which will be copy-pasted all over the frameworks, plugins, CMS scripts, etc.
So the cost of supporting the stopImmediatePropagation-on-the-document is null, but the PointerEvents support cost is very far from null.

>>>  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.
> Not once the drag behavior did start. Once you start dragging, you don't want any other gesture to happen using the pointers currently consumed by the drag behavior.

I didn't understand this argument. My point is that without capturing we (the API developers) may implement many behavoirs on the same DOM tree that will not interfere each other. In the capturing world our possibilities are significantly shorter, so this technology effectively removes some possibilities and add no one.

Konstantinov Sergey
Yandex Maps API Development Team Lead

Received on Tuesday, 9 April 2013 11:46:38 UTC