Re: Last Call comments

08.04.2013, 18:56, "Scott González" <scott.gonzalez@gmail.com>:
> 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.

Then why the pointerEvents are better for encapsulation? Placing the capturing onto the element in your scope not only affects the event flow in your scope, but every other script on page. There is no encapsulation at all with PointerEvents.

>
>> (b) Drag'n'Drop API.
>
> The Drag and Drop API is more cumbersome than the Pointer Events API.

But it isn't breaking the other scripts on page.

>
>> 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 am the developer and I do not want such model.

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

They're using it wrong, but the very spec makes it very simple to use 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()?

Partly. First of all, if you attach your listener once, no one can interfere you later. In second, there is no "essential cases" when you need to call 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."

That's very hard to provide real world use case when there is currently no implementations of the spec (hammer.js doesn't use capturing).

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

And what about encapsulation? Why my script needs to check if some other script on the page are doing something with capturing? And how do I make a decision whether to take the capturing away or not?

-- 
Konstantinov Sergey
Yandex Maps API Development Team Lead
http://api.yandex.com/maps/

Received on Monday, 8 April 2013 15:36:05 UTC