W3C home > Mailing lists > Public > public-webevents@w3.org > July to September 2013

Guidance for how implementations should handle a radius of 1

From: Rick Byers <rbyers@google.com>
Date: Thu, 8 Aug 2013 22:02:40 -0400
Message-ID: <CAFUtAY-n8u5cqVPzD=LngZGag3pEpYuVS0jmL97pSUC7EZs_Fg@mail.gmail.com>
To: "public-webevents@w3.org" <public-webevents@w3.org>
Cc: Yufeng Shen <miletus@google.com>
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?

Thanks,
   Rick
Received on Friday, 9 August 2013 02:03:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:55 UTC