Re: Can we change default radius to 0 in the touch events extensions

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

Apparently iOS 8 now provides an API for touch radius
<https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UITouch_Class/#//apple_ref/occ/instp/UITouch/majorRadius>,
and the Safari team is now interested in exposing radius as well:
https://bugs.webkit.org/show_bug.cgi?id=133642

The rest of the argument here is still valid for angle and force though
(though see my other fork of this thread for our principle on evolving
TouchEvents in general).

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.)
>
> --
> Sangwhan Moon [Opera Software ASA]
> Software Engineer | Tokyo, Japan
>