RE: Last Call comments

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.

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'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:

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]; }


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

Received on Friday, 22 March 2013 21:35:46 UTC