Re: Last Call comments

On Mon, Apr 8, 2013 at 10:36 AM, Konstantinov Sergey
<twirl@yandex-team.ru>wrote:

> 08.04.2013, 17:51, "Scott González" <scott.gonzalez@gmail.com>:
> > On Mon, Apr 8, 2013 at 7:50 AM, Sergey Konstantinov <
> twirl@yandex-team.ru> wrote: >> The capturing system is a meaningless
> artifact of IE6, why > implement it again? > > > <snip> Accessing the
> document is, of course, bad for composition. But accepting the wrong
> designed feature instead is much worse.
> > Do you have another proposal? I believe the only other solution that has
> been discussed is using the capturing phase. I honestly don't know of any
> web developers who use it. And we've already discussed why pointer capture
> is easier to work with.
>
> In my opinion there's no need in another proposal since we have (a)
> standard DOM Events capturing functionality,


We've already discussed why event capturing is bad for encapsulation, and
you agreed.


> (b) Drag'n'Drop API.
>

The Drag and Drop API is more cumbersome than the Pointer Events API.

In any case, there is no need in proposal which makes some common tasks
> unsolveable.
> May I ask, why we have to implement the third way to do the same thing?
>

Because this is the one API that provides the model that developers want?

>> I quickly read over jQuery code. The accidental capturing on the random
> node will completely break the following functionality:
> > What is creating "accidental capturing"? Who is creating the accident?
> How?
>
> Any other script on the page.
> We (the Yandex Maps API Team) are working in conditions, when our code is
> used on third-party websites. So we don't know whether the user code (or
> user framework, or user CMS, or user plugin) uses capturing interfering our
> code; and we cannot freely place the capturing ourseves for the same reason.
> Standard "document.addEventListener-with-capturing" approach is not
> interferrable and cannot ruin the third-party code.
>

So don't use it in your code. If the page that's including your code is
using pointer capture at a level higher than a map, it sounds like they're
using it wrong.


> >> - enter/leave events detection,
> > Perhaps in some low-level technical sense, but not in perceived reality.
> If someone wants pointer capture, then they're saying, "if the pointer
> leaves this element, we're going treat it as if that never happened.
> Browser, will you please treat that as reality?" Let's take the slider
> example from the spec. Imagine a class is added and removed as the pointer
> enters and leaves. If the pointer is down while hovering, then the thumb
> wants to capture the events. If the user moves the pointer down such that
> it leaves the thumb, the widget wants to continue to track the horizontal
> movement and continue sliding. Although the pointer has technically left
> the thumb, the widget is conveying to the page that this has not occurred.
> In other words, the pointer is still interacting with me, please do not
> respond to any actions performed outside of my physical space. Pointer
> capture provides a way to accomplish this.
>
> And again, there are lots of scripts on typical web page. This proposal
> makes the excellent opportunity to one of them to shoot off the legs of all
> other scripts on the page. There may be just some error in user script.
>

Doesn't this opportunity already exist with stopImmediatePropagation()?


> >
> > Similarly, if the pointer moves fast enough horizontally, the events
> will fire on some other element, which means that you have to actually bind
> to the document which is annoying.
>
> We are trying to solve "annoying" problem by creating the irrestible one.
>

I'm not sure what this means.


> >
> >> - $.live functionality, - $.handle functionality.
> > I'm not sure which version of jQuery you're looking at, but .live() was
> removed back in 1.9: http://jquery.com/upgrade-guide/1.9/#live-removed
>
> Okay, it's now called $.on; but the core functionality still relies on the
> event target's correctness.
>
>         handlers: function( event, handlers ) {
>                 var sel, handleObj, matches, i,
>                         handlerQueue = [],
>                         delegateCount = handlers.delegateCount,
>                         cur = event.target;
>
>                 // Find delegate handlers
>                 // Black-hole SVG <use> instance trees (#13180)
>                 // Avoid non-left-click bubbling in Firefox (#3861)
>                 if ( delegateCount && cur.nodeType && (!event.button ||
> event.type !== "click") ) {
>
>                         for ( ; cur != this; cur = cur.parentNode || this
> ) {
>
> So what will happen if the target is wrong?
>

So you're referring to delegated events. Again, the target is not "wrong",
it is adjusted as per the request of some script. Please provide a real
world use case where this is problematic. The only case you've provided
seems like a case where it's ok to say to the page author "Sorry, what
you're doing is going to break things."

>> Is this not enough? There is no way to detect such an unexpected
> intervention; there is also no way to prevent dead locks on capture
> setting. And I still don't see any examples when "capture is essential",
> except the dragging one, which could be easily solved using standard DOM
> Events functionality.
> > 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.