Re: Last Call comments

10.04.2013, 00:58, "Fran├žois REMY" <>:
>>  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.
> It would change exactly nothing. Have a look at my code, the two event handlers are completely independant and don't even know about each other and the order in which they fire. If I wanted the drag on the marker and the click on the map, I would simply intervert the role of "map" and "marker" in the event handling code, and nothing would break.

You just omit the (b): marker should check the targets of "down" and "up" events. That's the convenient way to detect, whether "click" event should occur after down-up event pair, or not.
Adding pointer targets checking ruins the whole scheme.

>>  Which paragraph of the spec defines such a behavior?
> I think it's implied by "Pointer capture allows the events for a particular pointer to be retargeted to a particular element other than the normal hit-test result of the pointer's location". Finding the window the pointer belong to is hit-testing related, so it should not be done. I can see how some browsers may prefer not to support that for OS-related reasons, but at least IE do so.

That behavior must be explicitly stated in the proposal in my opinion.

>>>>  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.
> I see no essential case where you would want to do stupid things with 'setPointerCapture' either :-) Seriously, for every case where you could do something stupid with 'setPointerCapture' I can find the exact dual case where you face the same issue using your document hook technique. But I think I'll grant you that someone could possibly use 'setPointerCapture' wrongly more easily if it ignores how to use event tunneling because of the way it is defined now (but I think I've a way to solve this, I'll probably come back with this later). However, in the root hook case, he will be forced to learn how to use it with the document's hook technique.

But the map-marker example isn't wrong: both sides (map and marker) are using the capture as recommended.

>>>>>  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.
> Well, what I mean is that you don't want the same pointer to be used by two gestures so, if you know that you're using the pointer, you may want to prevent to ancestors to use it, too. I've a very good example to show this: suppose you've a minimap inside another map, and the user start to drag from inside the minimap, you don't want the parent map to drag, too. This is why you would want to prevent the event from bubbling. You can imagine the same thing for nested scrollable area (as long as the inner area can scroll, the outer area should not see the pointermove events).

We never use stopPropagation (or stopImmediatePropagation) in such cases. If two behaviors are conflicting we make them to propagate over different trees or add the custom flag to the event.
The problem occurs when different behaviors on the different nodes are _not_ conflicting, but they have to use the same events.

> You could also use some other synchronizing technique, if you don't like stopping the event propagation. I can understand there are valid reasons to do so, notably to deal with codes that expect events to be fired, that's also a valid choice, but I've never had such problems with my own sites.

We may use synchronizing techniques when we control both sides, which is a rare situation in the modern web.

> I saw a reference before to "it will prevent me do things like show traces for touch input" which is wrong: for those kinds of things you would just watch the pointer events during the tunneling phase: this is what the tunneling phase is meant to ;-)
>>  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.
> This is false, and I can prove it. You lose absolutely nothing when you use setPointerCapture. Common, on most GUI languages you cannot have a reference to the document root, on some there is not even a bubling phase, and you have to rely on a pointer capture, and there is absolutely no use case you expressed which is impossible or hard to do in those languages.

I agree that capturing-on-the-document makes the script to operate out of its scope. That's not good, but, at least, you are not modifying the local scope of other scripts.
The danger of the capturing is the un-locality of its effect: capturing changes the scope of every other script on page. The special "captured" flag doesn't solve the problem: capturing still affects all scopes on the page.

> I like Benoit's vision of saying "just write some code". I'm busy for now with personal things but I will have some free time in the coming days, I'm going to try showing you how easy-to-use, non-conflicting & not-in-known-of-each-others gestures can be handled with setPointerCapture. In the mean time, I invite you to read my previous code, and see there's nothing 'crazy' about it: it just works and it feel very natural.

We spent six months writing the code for IE10, so we know all the advantages and disadvantages of this proposal very good, and we already wrote tons of code using PointerEvents (and MSGestures, too). The core idea of working with input of different origins using the same event set is good; but the implementation of this idea in this proposal is bad, both in general and specific.

Konstantinov Sergey
Yandex Maps API Development Team Lead

Received on Wednesday, 10 April 2013 09:46:21 UTC