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

On Thu, Jun 5, 2014 at 12:33 PM, Matt Brubeck <mbrubeck@mozilla.com> wrote:

> On 06/05/2014 09:13 AM, Rick Byers wrote:
>
>> Secondly, using X and Y for the radius is somewhat limiting.  X11 and
>> Android instead use an ellipse model of touch contact with touchMajor,
>> touchMinor and touchRotationAngle.  I've just learned that the Nexus 10
>> does a really good job of supporting this (you can see it by enabling "show
>> touch locations" in developer options).  I'm not aware of any device that
>> returns touch width/height so in practice chrome always reports
>> radiusX==radiusY.  So I'd prefer we change this to radiusMajor, radiusMinor
>> and rotationAngle properties.  OSes like Windows 8 that report contact
>> geometry in terms of width/height can still be properly supported -
>> rotationAngle would just always be 0, but the inverse is not true.
>>
> Earlier versions of the v2 spec had a "rotationAngle" property that worked
> like this:
>
> https://dvcs.w3.org/hg/webevents/raw-file/c8eccbb92b31/touchevents.html#
> widl-Touch-rotationAngle
>
> It was removed (by accident?) when the document was changed from Touch
> Events v2 to Touch Events v1 Extensions.
>

Yeah I think we removed it because we weren't aware of any implementations
that used it for anything reasonable (eg. Chrome hard-coded it to 0), so
didn't want to encourage use of it by websites.  In particular, the spec
didn't explicitly say how radiusX / radiusY should be interpreted when
there is a non-zero rotation angle.  Eg. if X11/Android returns Major=10,
Minor=5, Angle=45deg, then presumably the browser should use some math to
calculate the distance to the ellipse edge along each axis. I haven't
worked out the math - is it reversible so that an app could reconstruct the
ellipse? We still have a bug in Chrome here which you can see on a Nexus
10: we blindly report 'touchMajor' as radiusY and 'touchMinor' as radiusX -
assuming (without checking) that the orientation is 0.

Of course we could fix this by just specifying that radiusY is the radius
in the direction that _would_ be the Y axis if rotationAngle was 0, but
just using major/minor is still simpler and maps more directly to any
reasonable use.

Rick