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