Re: Evolving TouchEvents within the W3C

(I think the original thread served it's purpose, so continuing discussion
here.)

On Fri, Jun 6, 2014 at 11:04 PM, Rick Byers <rbyers@google.com> wrote:

> 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> wrote:
>
>> On Fri, Jun 6, 2014 at 12:37 PM, Rick Byers <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.
>

This indeed is important, and something that needs to be done. (This isn't
limited to touch input though, recently discovered exposing device hardware
keys [e.g. menu, back] down to DOM has to be fudged with "replacement keys"
as there isn't a standard that covers this quite well enough. But that's a
different thread belonging in some other mailing list which I'm not aware
of.)


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

I understand. Vetoing further is not going to advance the discussion, so
accepting the resolution as it is - the bit we should really be careful
about is to make sure that additions into TE get into PE, so content
authors won't end up having to listen to both events due to mutually
exclusive features. The additions above are risky in that regard, unless we
make sure that they get into PE.

Following that, it would be nice TE could be kept a strict subset of PE, in
which case PE would be the low level events that can be used to [*]
polyfill touch events for applications that only support TE, and any
application that wants to properly support or simply needs higher
granularity can tap straight into PE. (assuming that the polyfill is
probably not going to be as performant as the native event)

Slightly off topic, the browser that won't implement PE being #1 seems to
be limited to North America and Oceania. Android is king everywhere else.
(Where I come from Android and Chrome added up seems to have 90% market
share. Scary.)

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

W3C should come up with a Deprecation WG. (Partially serious. Please let me
know when window.open/close/opener is going to be put into a rocket and
shot off to another galaxy.)

Sangwhan (who is scratching his head wondering what to do about the TE
extensions for Presto)

[*] I'm not sure if this is in scope or not for Blink-in-JS though. (I
don't recall seeing any mention about events in the document)