RE: Capturing Problems Example

> And, in third: you cannot detect whether the event target is correct - maybe there is already some capturing in action.

Guy, what's wrong with you? If there's already a capture, and that an event fires, then setting the capture on the event's target will be a no-op because this is already the element which got the capture, and it will do exactly what's wanted because it guarantees you continue to see this event in the future, which is exactly the reason why you would call this code. 

To sum up: it does what you expect, there's nothing wrong with it.


Also, there's not "one" correct way of setting a capture. What if your user start touching just outside an element but its parent decide to set the capture on its child that's the nearest neighbor of the initial tap? That would be a perfectly reasonable behavior (for example for a touch keyboard and its keys), and you can't do that using the "just allow the usual behavior thing".

The only thing I agree with you, at this point, is that the "most commonly wanted & conflict-safe behavior" should be recommended & easier to use than a more custom solution (setPointerCapture), something which is not completely true with the current API because it's recommendation-agnostic (you can set the capture on any element with the same ease of use).

That doesn't mean there's anything wrong with it, btw, even if I agree with you some minor accommodations (ie: event.capturePointer() to set the capture on the event target + don't overwrite an existing capture to a child element) could *potentially* reduce the amount of bad code on the web in the future.

Received on Friday, 12 April 2013 16:11:53 UTC