W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2013

RE: Last Call comments

From: Konstantinov Sergey <twirl@yandex-team.ru>
Date: Wed, 20 Mar 2013 14:12:58 +0400
To: public-pointer-events@w3.org
Message-Id: <841363774378@webcorp1e.yandex-team.ru>
> 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.

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

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

Konstantinov Sergey
Yandex Maps API Development Team Lead
Received on Wednesday, 20 March 2013 10:13:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:24 UTC