RE: Last Call comments

> 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.


> 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.


> >> 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.


> >>> 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).

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.

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 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.

Received on Tuesday, 9 April 2013 20:59:19 UTC