Re: Last Call comments

On Mon, Apr 8, 2013 at 10:36 AM, Konstantinov Sergey

> 08.04.2013, 17:51, "Scott González" <>:
> > On Mon, Apr 8, 2013 at 7:50 AM, Sergey Konstantinov <
>> 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:
> 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 =;
>                 // 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.

Received on Monday, 8 April 2013 15:04:43 UTC