Re: Last Call comments

On Mon, Mar 25, 2013 at 2:30 AM, Konstantinov Sergey
<twirl@yandex-team.ru>wrote:

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

Jacob's description is accurate for the problems we've seen with this in
Chrome.  Here's a post I wrote going into this in more detail:
https://plus.google.com/115788095648461403871/posts/cmzrtyBYPQc, and here's
an artificial test page that demonstrates the issue:
http://www.rbyers.net/janky-touch-scroll.html.  If you can guarantee that
nothing on the main thread (JavaScript, layout, etc.) will ever take longer
than 16ms then there's no problem.  But that is practically impossible in
the limit, and we've seen it be a real problem in practice.  To me and many
of the other Chrome engineers I've talked to, this is the single biggest
benefit of the pointer event model and one that is worth giving up a least
a little flexibility for.

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