RE: Evolving TouchEvents within the W3C

I’m concerned by this and I mirror most of Sangwhan’s feedback. The Touch Events Community Group was founded on the purpose of “determining differences in touch event behavior between browsers” and to “define the relationships between touch-pointer-mouse.”  Its genesis was to help refine Touch Event interoperability and to help rationalize Touch Events with Pointer Events. Specifically, the group was created not too longer after the Touch Events WG resolved to close and abandon pursuing the V2 spec as a Recommendation in favor of transitioning towards Pointer Events. [1] I don’t see these types of changes (“evolving touch events”) as in line with those goals or your previous description of your position on future work on the Touch Events spec [2]. More concerning is the back-channeling with Apple that’s occurring to try to evolve the API. [3] To me, this doesn’t seem to be an effective way to move the web forward.

If you ask web developers what the biggest problem is for touch, they’ll tell you interoperable APIs. But I think work on evolving TE further will only further fragment things as Sangwhan points out (Opera might remove them, Firefox & IE may/may not implement, Apple discussion has to happen through back-channelling, etc.). Pointer Events is on track to provide the best interop across browsers (IE, FF, partial support in Chrome/Opera, potential partial support in Safari).

I’d prefer we focus on the tasks that drive towards better interop across browsers. Errata for the TE spec where it doesn’t match implementations, changes to TE or PE that help drive interop, new APIs that allow better coexisting of touch-pointer-mouse, etc.

-Jacob

[1] http://www.w3.org/2012/09/25-webevents-minutes.html#item03

[2] http://lists.w3.org/Archives/Public/public-touchevents/2014Feb/0005.html

[3] https://bugs.webkit.org/show_bug.cgi?id=133642


From: Rick Byers [mailto:rbyers@google.com]
Sent: Friday, June 6, 2014 7:04 AM
To: Sangwhan Moon
Cc: Matt Brubeck; public-touchevents@w3.org; Jared Duke; Anne van Kesteren
Subject: Evolving TouchEvents within the W3C

Changing subject to reflect the much broader scope (which frankly has probably deserved a thread on this list for while <grin> - we talked about it in a recent PEWG telcon, but not on the list).

+Anne since we had some good discussions about this at BlinkOn

On Fri, Jun 6, 2014 at 9:02 AM, Sangwhan Moon <smoon@opera.com<mailto:smoon@opera.com>> wrote:
On Fri, Jun 6, 2014 at 12:37 PM, Rick Byers <rbyers@google.com<mailto:rbyers@google.com>> wrote:
Thanks Matt.  I've made the following changes and pushed an update here<https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html>:

  *   added rotationAngle back, and updated text for radiusX to indicate that it's along the axis specified by rotationAngle, while radiusY is perpendicular to that axis.
  *   changed unsupported radius value from 1 to 0
  *   changed radius units from long to float (matching proposed screenX/screenY changes in the v1-errata spec)
  *   updated document date
  *   added myself as an editor (I assume since these changes are non-trivial that's the right procedure, let me know otherwise).
Any feedback?

Regarding rotation and radius, while I wasn't a huge fan myself, the biggest reason for dropping those properties was to ensure interoperability across implementations. Considering the fact that:

1. WebKit will most likely not change.
2. Gecko's values are dummies values, which can be removed.
3. Presto will not change.
4. IE will most likely not implement.

Unless Mozilla is actually intending to implement it with real values, I really think existing implementations should drop support for radius and angle and move that over to the scope of the next iteration of PointerEvents rather than try to completely scatter interoperability around. Chromium being the only implementation of a already dead spec that will break interoperability doesn't sound like a good direction to drive towards.

So the only implementation that has even a remote possibility of getting these changes implemented is Gecko, and unless Mozilla will implement a patch to a dead spec I don't think we should do this - I would actually vote on trying to *remove* these properties on existing implementations and move it into the scope of PE where we can get at least one more implementation to ship. Changing it and making Chromium the only compliant implementation doesn't seem right.

That said, I probably won't (or more of, can't) proactively try to remove it on Chromium upstream. (Although there is a chance that I might suggest removal within the scope of Opera.)

I understand your concern.  We're in a tough place here with evolving input in blink.  The top priority for blink right now is to make our implementation of the web platform on mobile more competitive with native mobile platforms.  This involves urgently improving input APIs.  Radius/rotation definitely aren't important here, but I think it's most valuable to have this discussion on the abstract principle since the argument also applies to things that are important.  Interoperability here is definitely key, but unfortunately the #1 browser on mobile isn't interested in implementing pointer PointerEvents, so for maximum interoperability we feel we must also work to improve TouchEvents (and we're having some limited success engaging with Apple on this front - eg. fractional co-ordinates<https://bugs.webkit.org/show_bug.cgi?id=133180> [1]).

I don't think the strategies are mutually exclusive.  I intend to continue to work in the PEWG, and hopefully someday we'll have an API that all major browsers implement (or at a minimum, have the key pieces such that high-quality JavaScript implementations are possible).

But in parallel we feel we absolutely must continue to incrementally evolve TouchEvents in blink.  There are lots of other parts of the web we'd throw out and replace with something brand new if we could, but that's just not how evolution of the web normally works.  Our deepest hope is that at least some of the other members of the TECG will be interested in collaborating with us on improving TouchEvents.  But if this doesn't align with the strategic priorities for Opera, Firefox or IE then I understand, and I'm sure we'll still be able to collaborate on other places where input improvements are needed (I'm quite excited by the long list of ideas we came up with for the upcoming face-to-face).

Rick

[1] https://bugs.webkit.org/show_bug.cgi?id=133180


--
Sangwhan Moon [Opera Software ASA]
Software Engineer | Tokyo, Japan