Intent to implement and ship: unprefixed Touch radius and force

[Rick Byers]

Contact emails

rby...@chromium.org

Spec

http://www.w3.org/TR/touch-events-extensions/

Note that touch events extensions is technically not a W3C spec, but a working group note.  This is because there is no longer any W3C working group working on touch events.  I'm working on a process for updating the touch event spec and so will try to move radius and force into some future official version of the spec.

Summary

We've shipped webkitRadiusX, webkitRadiusY and webkitForce properties on the Touch object for many years.  We should unprefix these with a path to eventually deprecating the prefixed versions.

Motivation

Having radius is useful for drawing applications and well supported by typical touch hardware (eg. see http://www.rbyers.net/paint.html for a example of plotting raw touch events with radius).

Force is of less certain value (as it's support varies across devices and sensor technologies) but is available in native input APIs and we already plumb it through from MotionEvent.getPressure on Android.

Unprefixing these is just a minor cleanup and cross-browser compat improvement.

Note that we also expose a webkitRotationAngle property today, but I'm not aware of any scenario in which it actually works (eg. it's not actually plumbed through on Android and hardware support is limited), and so we didn't include it in the list of properties in the touch events extensions.  We may want to add standard support in the future, especially if we choose to tackle stylus scenarios.  But in the mean time I'll separately attempt (not covered by this intent) to deprecate/remove the prefixed property.

Compatibility Risk

Low.  We've been shipping this functionality for years, this just updates the name to be unprefixed.  This matches Firefox: https://developer.mozilla.org/en-US/docs/Web/API/Touch.  Safari doesn't support this, and IE doesn't use touch events but IE's pointer events are conceptually the same (with width, height and pressure properties).

There could be arguments about whether we should really use radiusX/radiusY instead of major/minor/angle (which is what Android does) but I don't think it's worth worrying about at this point.  In practice the hardware we care most about (commercial phone/table touchscreens) typically has a single radius value and so the difference is irrelevant. 

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes, except Mac doesn't support true touch input (only devtools emulation and synthetic events).

OWP launch tracking bug?

https://crbug.com/378780

Link to entry on the feature dashboard

None, this is probably too trivial to worry about.

Requesting approval to ship?

Yes

[PhistucK]

"Safari doesn't support this" - any variation of this? prefixed, unprefixed, or under any other name or variant?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

On May 30, 2014 3:43 AM, "PhistucK" <phis...@gmail.com> wrote:

"Safari doesn't support this" - any variation of this? prefixed, unprefixed, or under any other name or variant?

Not as far as I'm aware. Apparently iOS has no public APIs for getting such information from Apple touch hardware (although some people have found undocumented/banned private APIs), so it makes sense that Mobile Safari doesn't have/want any APIs for it.

[Eric Seidel]

Do we have customers already using the prefixed versions? I guess
we've already shipped them, so the option of removing this
functionality to match iOS isn't a good one. It concerns me slightly
that many mobile customers are unlikely to see this API on Safari for
a very long time -- makes me question the utility of these APIs.

[Rick Byers]

On Fri, May 30, 2014 at 1:49 PM, Eric Seidel <ese...@chromium.org> wrote:

Do we have customers already using the prefixed versions?  I guess
we've already shipped them, so the option of removing this
functionality to match iOS isn't a good one. It concerns me slightly
that many mobile customers are unlikely to see this API on Safari for
a very long time -- makes me question the utility of these APIs.

Yeah it's certainly debatable.  I believe I saw a painting based website at one point that was using radius (other than my test pages) but I can't find it now.  If anyone is using it, it's certainly rare.  We had a bug in Chrome Android for a long time (still in M34 I think) that the radius scale was off - so if anyone was using it they'd need some hacks. We'll have a better idea once M36 goes stable and we have metrics.

That said, it's part of the Android platform and is used by some Android apps (eg. a quick search turned up Infinite Painter, but I'm surprised Autodesk's Sketchbook doesn't appear to use radius/pressure).  Removing existing functionality from Chrome that's in use by Android apps doesn't exactly seem aligned with our primary mission <grin>.  Try playing with http://www.rbyers.net/paint.html on your phone - having radius definitely adds value in some scenarios.  Touch geometry is also part of PointerEvents (and supported in IE10+), removing it from TouchEvents would be an additional (debatable) argument for why PointerEvents are superior.  There's also ongoing debate for how best to support Wacom tablet scenarios in Chrome, with discussion of overloading touch events somehow - Wacom typically wants at LEAST radius and pressure information (typically also pen tilt).

I'm happy to leave things as-is for now if you prefer.  I was just updating the radius units to be double along with the co-ordinates and felt I should really work to clean up these prefixed properties.

[Rick Byers]

On Fri, May 30, 2014 at 3:01 PM, Rick Byers <rby...@chromium.org> wrote:

On Fri, May 30, 2014 at 1:49 PM, Eric Seidel <ese...@chromium.org> wrote:

Do we have customers already using the prefixed versions?  I guess
we've already shipped them, so the option of removing this
functionality to match iOS isn't a good one. It concerns me slightly
that many mobile customers are unlikely to see this API on Safari for
a very long time -- makes me question the utility of these APIs.

Yeah it's certainly debatable.  I believe I saw a painting based website at one point that was using radius (other than my test pages) but I can't find it now.  If anyone is using it, it's certainly rare.  We had a bug in Chrome Android for a long time (still in M34 I think) that the radius scale was off - so if anyone was using it they'd need some hacks. We'll have a better idea once M36 goes stable and we have metrics.

That said, it's part of the Android platform and is used by some Android apps (eg. a quick search turned up Infinite Painter, but I'm surprised Autodesk's Sketchbook doesn't appear to use radius/pressure).  Removing existing functionality from Chrome that's in use by Android apps doesn't exactly seem aligned with our primary mission <grin>.  Try playing with http://www.rbyers.net/paint.html on your phone - having radius definitely adds value in some scenarios.  Touch geometry is also part of PointerEvents (and supported in IE10+), removing it from TouchEvents would be an additional (debatable) argument for why PointerEvents are superior.  There's also ongoing debate for how best to support Wacom tablet scenarios in Chrome, with discussion of overloading touch events somehow - Wacom typically wants at LEAST radius and pressure information (typically also pen tilt).

One more argument for keeping at least radius exposed: we use it internally for hit testing (the candidate region for touch fuzzing is determined by the supplied radius when present).  This means you can target a small link more precisely by using the tip of your finger, where a fat finger pad will consider more targets underneath it.  We haven't done the analysis to prove this is better in practice than using a fixed candidate region, but it's reasonable to suspect that it is.  The rational web platform principles suggest that anything we're relying on internally like this should be exposed to the application so that it can re-implement/modify our behavior (in particular, fuzzing applies just to click/contextmenu events, it's not unreasonable for a page to want to apply a similar algorithm to touchstart events).

[Ojan Vafai]

LGTM. Firefox ships this, it's in a spec that hasn't changed in a year and a half (i.e. it's relatively stable) and this exposes Android native functionality. Those all seem to be good reasons for shipping it (and thus unprefixing) even if we think the use-cases for it are somewhat niche.

[Rick Byers]

Apparently iOS 8 now provides an API for touch radius, and the Safari team is now interested in exposing radius as well: https://bugs.webkit.org/show_bug.cgi?id=133642

Rick

[Adam Barth]

LGTM.  This will help us deprecate and eventually remove the prefixed versions.

[TAMURA, Kent]

LGTM3

--
TAMURA Kent
Software Engineer, Google