Re: Guidance for how implementations should handle a radius of 1

On Thu, Aug 8, 2013 at 7:02 PM, Rick Byers <rbyers@google.com> wrote:
> Hi,
> I know touch events V2 is dead, but I'm considering changing Blink's
> behavior with respect to radius and so wanted to see if anyone had feedback
> here.
>
> The draft v2 spec said that radius should be '1' if no value is known
> (https://dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html#widl-Touch-radiusX).
> This poses a problem for any app using this - how exactly should they
> interpret a 1 since it could mean either 'unknown' or 'very small'.  In my
> silly little test paint program (http://www.rbyers.net/paint.html) I used a
> heuristic: if I EVER see a radius >1 then set a flag saying that radius is
> known to be supported and only then use radius values for anything
> (otherwise use a suitable default that's much larger than 1).
>
> This breaks down in multi-monitor configurations where one monitor supports
> radius and one doesn't (eg. a chromebook pixel with external touchscreen - a
> real scenario we've heard users trying to do).
>
> One not very attractive option is to break compat with existing
> implementations by fixing the definition (eg. I think '0' or 'undefined'
> would have been better than '1' here).  A simpler and more pragmatic
> improvement I see is to ban the use of 1 as a real radius.  Eg. I'm
> considering having blink bump any REAL radius value of 1 up to 2 to avoid
> the ambiguity.  Any objections to making that the recommendation of the WG?

I'm okay with either that last suggestion (if the value would be 1,
instead report 2), or adding an additional boolean to the event saying
whether the value is actually known or just guessed at.

I don't like returning 0 or undefined, because it means that naive
code that just acts on the radius directly will break or do unexpected
things.  It's nice to support naive code when it can be done easily.

~TJ

Received on Friday, 9 August 2013 03:09:53 UTC