Re: Last Call comments

23.03.2013, 01:34, "Jacob Rossi" <Jacob.Rossi@microsoft.com>:
> On Wed, Mar 20, 2013 at 3:12 AM, Konstantinov Sergey <twirl@yandex-team.ru> wrote:
>
>>> šThat very possibility that an event might cancel it means we have to wait on script.
>> šI opened test page with arbituary touch event prevention on iPad and played with it for ten minutes. No even minor glitch occured, which make me think that technical problems are avoidable.
>> šSee konstantinov.cc/test.html You may note that we fail to produce the same behavior in IE10.
>
> If I understand your test page's scenario correctly, it's that you want to handle events on the map (e.g. to move it around, load in new map tiles, etc.) but you want native panning/zooming when touching the balloon flyout. If that's right, then I think you just need touch-action:auto on the ymaps-b-balloon class. Let me know if I misunderstood the scenario.
>

You understand it correctly except for one moment: we use different techniques in different browsers, so we could easily get the situation when both balloon and map are rendered on the same canvas. Then we have no possible means to produce desirable behavior except to place a fake transparent html element on top of the map/balloon canvas. I think we should not accept specs that requires to do so.

> It's certainly possible to build smooth experience on some pages when using the preventDefault() approach. But the engineers in this group representing browsers that have implemented touch events will tell you this doesn't work in many cases. Touch Events have demonstrated janky scrolling impact on many pages. Modern touch browsers typically use multi-threaded scrolling to achieve top performance. However, the preventDefault() dependency creates a required sync between the scrolling thread and JavaScript/UI thread, which blocks the browser's ability to start the pan/zoom right away. Such a block makes it impossible to reliably achieve the industry goal of getting extremely low latency panning/zooming.
>

I see no comments from Webkit or Gecko engineers there.
The example page are very complex and contains a huge pack of HTML5 technologies - Canvas and CSS 3D transforms, to name a few - and 300 Kb obfuscated JS code. I still see no problems in Safari Mobile.

>>> šI'm not sure I follow the issue here. Is it that you believe the pointer model is difficult for multi-touch? Do you have a specific example that's more difficult with PE than TE? Generally speaking, I've heard the opposite of this (i.e. that pointer events are easier than touch events for multi-touch).
>> šWe (the Yandex Maps API Team) implemented both the Safari and IE10 event model code. So it's not just a belief - I'm pretty sure that pointer events code are far more complicated and unobvious than touch events one.
>>
>> šGenerally the code which works with multi input has absolutely nothing in common with the single input code. The interface responses on single and multi input are absolutely different in the majority of cases.
>>
>> šSafari model is quite reasonable here: you listen "mouse*" events in your single-input code and "touch*" events in your multi-input code. Of course, this is not good, but that is just the naming problem.
>>
>> šPointer model makes you write the dispatcher which is watching pointer events and separates single-input and multi-input. I see no reason in having such a dispatcher.
>> šFurthermore, in Safari Touch model you have all the information about every touch on the page in your touchmove event. In pointer system you have to write more code to handle such a simple thing.
>
> Exposing a "pointerList" is something that's been discussed and might be considered in V2 (I added this to the v.Next use cases wiki [1]), which I think well help your problem. Though it's fairly trivial to build your own in script:
>

Than maybe we should wait for 2.0 specification? This 1.0 spec has too many flaws.

> var pointerList = []; //Array off all active pointers, indexed by pointer ID, that has all the latest info about each
>
> window.addEventListener("pointerdown", addPointer, true);
> window.addEventListener("pointermove", addPointer, true);
> window.addEventListener("pointerup", remPointer, true);
> window.addEventListener("pointercancel", remPointer, true);
>
> function updatePointer(e) { pointerList[e.pointerId] = e; }
> function remPointer(e) { delete pointerList[e.pointerId]; }

I think that w3c spec should not force the developers to write such code instead of simple "e.touches.length".

In my own opinion we should provide two sets of events:
"pointer*" - for the single-pointer events (="mouse*" events in Safari Mobile)
"multipointer*" - for the multi-pointer events (="touch*" events with touches.length > 1 in Safari Mobile)

"pointer*" events should flow when there is only one input device active and should stop when the second device is added.
"multipointer*" events should flow when there are two or more devices active and should contain full information regarding all devices.

That would be the ideal model which saves tons of code. Current "pointerevents" spec saves no single line of code, provides a pack of strange situations and forces the developer to use dirty workarounds to count the pointers and to obtain pointer positions.

>
>>> šSo it effectively gets a reserved pointerId and 1 is convenient for that.
>> šI see absolutely no sense in this convention. We lose some possibilities but acquire nothing instead. Same for the capturing.
>>> šThere are clear scenarios for it, like the slider control example included in the spec.
>> šAgain no sense. document.addEventListener('event', cb, true) is simpler and more consistent way to do that. Again, we lose some possibilities (to place the capturing on the two html nodes simultaneously), produce some potential bugs and aquire nothing instead.
>
> Using setPointerCapture() is completely optional. Having the feature in the spec does not cause you to lose possibilities--you're still welcome to use the capturing phase if you'd prefer.

Absolutely not.
We (the Yandex Maps API Team) are writing the technology which is working on third-party websites. There are lots of other code on the page - frameworks, CMS code, utilities, and just our user code. Any piece of this code could freely place the capturing on any dom element on the page, and we would never be aware of that. It is impossible to detect whether the event's target property is correct or it is altered by capturing. setPointerCapture effectively breaks the back compatibility!

Furthermore, if we try to place our own capturing we can easily produce a deadlock, when two different scripts on page are placing the capturing on two different nodes and are trying to reinstate it on 'losecapture' event.

Why should we allow this ambiguous and undetectable behavior? Especially when this behavior produce no additional possibilities?

> I find the capture methods more readable and less šbug prone, personally. When reading code, it's easy to miss the difference between šdocument.addEventListener('event', cb, true) and document.addEventListener('event', cb, false), whereas explicit methods to set and release it are a bit more obvious to me. Also, unlike capture phase, the methods also affect the target property of the event, which is convenient in some cases. But again, completely optional and their presence in the spec shouldn't prevent you from using the capture phase approach if that's your preference.
>
> -Jacob

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

Received on Monday, 25 March 2013 09:32:02 UTC