Intent to ship: CSS touch-action

3,232 views
Skip to first unread message

Rick Byers

unread,
Mar 11, 2014, 12:03:39 AM3/11/14
to blink-dev
Contact emails

Spec

Summary
touch-action is a CSS property that controls filtering of gesture events, providing developers with a declarative mechanism to selectively disable touch scrolling (in one or both axes), pinch-zooming or double-tap-zooming.  Benefits include:
  • Provides precise control over the dreaded 300ms click delay on mobile
  • Reliably enables side-swipe UIs (frees libraries from having to predict when exactly scrolling may start on different browsers)
  • Enables high-fidelity polyfills of pointer events (eg. as in Polymer)
  • Provides a declarative signal to blink (and potentially the compositor) about the developers intent wrt. touch input - eg. providing a potential solution the touchstart ACK timeout problem
  • Reducing confusion around the highly-overloaded response to preventDefault on touch events
  • A prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread
Link to “Intent to Implement” blink-dev discussion
Note that this intent-to-ship does NOT yet include the additional 'touch-action-delay' proposal I mentioned in this thread.  Touch-action by itself isn't sufficient for never-blocking scroll, but it is a big step towards making it possible.

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes, except doesn't do anything useful on Mac since Mac doesn't support touchscreens (and devtools touch emulation doesn't yet emulate gestures - crbug.com/337142). 

Demo link
I'll create a simple demo page later, but here are a few different ones that show different things:
EventTest for logging events - toggle the touch-action: none property in config and notice the effect on scrolling/zooming
Touch ACK timeout test page - if touch-action is supported a 3rd box shows up which can be used to demonstrate the impact of touch-action: none on the touchstart timeout
Blink tests for a variety of different configurations: simple, overflow, pan, shadow-dom, parsing

Compatibility Risk
touch-action is relatively stable and non-controversial.  IE10 shipped an -ms prefix implementation of it, and IE11 ships an implementation fully compatible with the standard.  Firefox now has an implementation behind a flag which they expect to enable soon.  The biggest risk is that we have not gotten any public signals from Apple (Apple is opposed to the larger pointer events API, but I haven't heard any specific objection to touch-action).

The 'manipulation' property was only just recently added to the standard, but it's a simple extension that has been present in IE since the beginning and will be supported by Firefox, so I don't consider it to carry any greater risk even though it's not yet part of the CR version of the spec.

OWP launch tracking bug?

Link to entry on the feature dashboard

Darin Fisher

unread,
Mar 11, 2014, 12:50:21 AM3/11/14
to Rick Byers, blink-dev
Questions:

1) In section 9 of the spec, it says "For touch input, the default action of any and all pointer events must not be a manipulation of the viewport (e.g. panning or zooming)." I realize that we don't support pointer events, but it seems like the intent of the spec is for touch-action to be an opt-in rather than an opt-out. It seems like you are proposing that we treat it as an opt-out instead.

2) Is "touch-action: manipulation" the magic sauce to disable the 300ms click delay without precluding panning or zooming?

3) Would it make sense for touch-action to be extracted from this spec to live in its own spec?

-Darin

Rick Byers

unread,
Mar 11, 2014, 10:57:28 AM3/11/14
to Darin Fisher, blink-dev
On Tue, Mar 11, 2014 at 12:50 AM, Darin Fisher <da...@chromium.org> wrote:
Questions:

1) In section 9 of the spec, it says "For touch input, the default action of any and all pointer events must not be a manipulation of the viewport (e.g. panning or zooming)." I realize that we don't support pointer events, but it seems like the intent of the spec is for touch-action to be an opt-in rather than an opt-out. It seems like you are proposing that we treat it as an opt-out instead.

touch-action is opt-out for all cases in the sense that 'auto' is always the default (all actions permitted) and you specify when you want to turn different actions off.

This text here about the "default action" has nothing directly to do with touch-action, it's talking in the DOM Events L2 terms about event cancellation, saying that calling preventDefault on a PointerEvent should not suppress scrolling/zooming.

So touch-action is fundamentally the exact same thing for both browsers with and without pointer events.  The key difference is that browsers with touch events have an ADDITIONAL constraint (covered by the touch events spec) that scrolling/zooming  cannot be started until the touch events have been sent to JavaScript and we know their disposition.

2) Is "touch-action: manipulation" the magic sauce to disable the 300ms click delay without precluding panning or zooming?

Yes.  It disables double-tap zoom but not pinch-zoom.

3) Would it make sense for touch-action to be extracted from this spec to live in its own spec?

I'm not sure.  It should certainly all make sense outside the context of pointer events.  There's one paragraph there now that no longer applies to Chrome's implementation even with s/pointer/touch/ (the 'sends pointercancel on scroll' bit).  At a minimum I think we should move that paragraph out of section 9.1 (since it's about pointer event behavior, not about touch-action per se).  I'll ask the WG how much extra work / bureaucracy there would be to splitting touch-action out to it's own spec.  If we could do it within the strict confines of the pointer events WG then it may not be that bad.  We probably can't mention touch events explicitly, but we shouldn't need to mention any specific type of event at all.

Rick Byers

unread,
Mar 11, 2014, 3:02:02 PM3/11/14
to Darin Fisher, blink-dev
On Tue, Mar 11, 2014 at 10:57 AM, Rick Byers <rby...@chromium.org> wrote:
On Tue, Mar 11, 2014 at 12:50 AM, Darin Fisher <da...@chromium.org> wrote:
Questions:

1) In section 9 of the spec, it says "For touch input, the default action of any and all pointer events must not be a manipulation of the viewport (e.g. panning or zooming)." I realize that we don't support pointer events, but it seems like the intent of the spec is for touch-action to be an opt-in rather than an opt-out. It seems like you are proposing that we treat it as an opt-out instead.

touch-action is opt-out for all cases in the sense that 'auto' is always the default (all actions permitted) and you specify when you want to turn different actions off.

This text here about the "default action" has nothing directly to do with touch-action, it's talking in the DOM Events L2 terms about event cancellation, saying that calling preventDefault on a PointerEvent should not suppress scrolling/zooming.

So touch-action is fundamentally the exact same thing for both browsers with and without pointer events.  The key difference is that browsers with touch events have an ADDITIONAL constraint (covered by the touch events spec) that scrolling/zooming  cannot be started until the touch events have been sent to JavaScript and we know their disposition.

2) Is "touch-action: manipulation" the magic sauce to disable the 300ms click delay without precluding panning or zooming?

Yes.  It disables double-tap zoom but not pinch-zoom.

3) Would it make sense for touch-action to be extracted from this spec to live in its own spec?

I'm not sure.  It should certainly all make sense outside the context of pointer events.  There's one paragraph there now that no longer applies to Chrome's implementation even with s/pointer/touch/ (the 'sends pointercancel on scroll' bit).  At a minimum I think we should move that paragraph out of section 9.1 (since it's about pointer event behavior, not about touch-action per se).  I'll ask the WG how much extra work / bureaucracy there would be to splitting touch-action out to it's own spec.  If we could do it within the strict confines of the pointer events WG then it may not be that bad.  We probably can't mention touch events explicitly, but we shouldn't need to mention any specific type of event at all.

I had a brief chat with the PointerEvents WG about this in our conf call today.  The group is opposed to separating touch-action out from the PointerEvents specification for the following reasons:

First, although touch-action makes perfect sense without pointer events, pointer events doesn't really make sense without touch-action.  Its felt that separating them would create a very awkward dependency between the pointer events specification and the touch-action specification.

Secondly, Mozilla and Microsoft are committed to trying to transition the web to pointer events as the future input model for the web.  Although they're happy that Chrome is implementing touch-action, they're understandably not really motivated to put a bunch of extra effort into making it easier for browsers to avoid implementing pointer events.

Overall I think it's reasonable to ensure that section 9.1 can stand on it's own and apply to browsers that choose not to implement pointer events, but (unless I'm missing some benefit) I don't think the value of separating it into it's own spec is worth the effort and political frustration - especially at this late stage in the spec's lifetime.

Darin Fisher

unread,
Mar 11, 2014, 3:05:54 PM3/11/14
to Rick Byers, blink-dev
On Tue, Mar 11, 2014 at 12:02 PM, Rick Byers <rby...@chromium.org> wrote:
On Tue, Mar 11, 2014 at 10:57 AM, Rick Byers <rby...@chromium.org> wrote:
On Tue, Mar 11, 2014 at 12:50 AM, Darin Fisher <da...@chromium.org> wrote:
Questions:

1) In section 9 of the spec, it says "For touch input, the default action of any and all pointer events must not be a manipulation of the viewport (e.g. panning or zooming)." I realize that we don't support pointer events, but it seems like the intent of the spec is for touch-action to be an opt-in rather than an opt-out. It seems like you are proposing that we treat it as an opt-out instead.

touch-action is opt-out for all cases in the sense that 'auto' is always the default (all actions permitted) and you specify when you want to turn different actions off.

This text here about the "default action" has nothing directly to do with touch-action, it's talking in the DOM Events L2 terms about event cancellation, saying that calling preventDefault on a PointerEvent should not suppress scrolling/zooming.

So touch-action is fundamentally the exact same thing for both browsers with and without pointer events.  The key difference is that browsers with touch events have an ADDITIONAL constraint (covered by the touch events spec) that scrolling/zooming  cannot be started until the touch events have been sent to JavaScript and we know their disposition.

Ah, I see. Thanks for clarifying.
 

2) Is "touch-action: manipulation" the magic sauce to disable the 300ms click delay without precluding panning or zooming?

Yes.  It disables double-tap zoom but not pinch-zoom.

Got it.
 

3) Would it make sense for touch-action to be extracted from this spec to live in its own spec?

I'm not sure.  It should certainly all make sense outside the context of pointer events.  There's one paragraph there now that no longer applies to Chrome's implementation even with s/pointer/touch/ (the 'sends pointercancel on scroll' bit).  At a minimum I think we should move that paragraph out of section 9.1 (since it's about pointer event behavior, not about touch-action per se).  I'll ask the WG how much extra work / bureaucracy there would be to splitting touch-action out to it's own spec.  If we could do it within the strict confines of the pointer events WG then it may not be that bad.  We probably can't mention touch events explicitly, but we shouldn't need to mention any specific type of event at all.

I had a brief chat with the PointerEvents WG about this in our conf call today.  The group is opposed to separating touch-action out from the PointerEvents specification for the following reasons:

First, although touch-action makes perfect sense without pointer events, pointer events doesn't really make sense without touch-action.  Its felt that separating them would create a very awkward dependency between the pointer events specification and the touch-action specification.

Secondly, Mozilla and Microsoft are committed to trying to transition the web to pointer events as the future input model for the web.  Although they're happy that Chrome is implementing touch-action, they're understandably not really motivated to put a bunch of extra effort into making it easier for browsers to avoid implementing pointer events.

Overall I think it's reasonable to ensure that section 9.1 can stand on it's own and apply to browsers that choose not to implement pointer events, but (unless I'm missing some benefit) I don't think the value of separating it into it's own spec is worth the effort and political frustration - especially at this late stage in the spec's lifetime.

OK, thanks for the follow-up. Sounds reasonable to me.

LGTM to ship.

-Darin

Adam Barth

unread,
Mar 12, 2014, 1:33:53 PM3/12/14
to da...@chromium.org, rby...@chromium.org, blin...@chromium.org
LGTM2

Ojan Vafai

unread,
Mar 12, 2014, 1:36:03 PM3/12/14
to Adam Barth, Darin Fisher, Rick Byers, blink-dev
LGTM3

Rick Byers

unread,
Mar 12, 2014, 1:39:19 PM3/12/14
to Ojan Vafai, Adam Barth, Darin Fisher, blink-dev
Thanks everyone!

I've put a high-level demo page together here: http://www.rbyers.net/touch-action.html.

Note there are a couple bugs still in the queue this week (blocking the master bug), so I'll flip the bit after those fixes land.

Rick

PhistucK

unread,
Mar 12, 2014, 3:33:02 PM3/12/14
to Rick Byers, Ojan Vafai, Adam Barth, Darin Fisher, blink-dev
Thank you very much for your work on this, I feel this is a really good addition to the platform (even though it is not generic since it refers specifically to touch input while I can only vaguely imagine a property that handles any kind of old or new input types and their default effects).
I wish this would have existed four years ago. :)

And for the sake of correctness -
"manipulation" is not a property as stated (twice) in the intent, but a value of the "touch-action" property.


PhistucK


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

Rick Byers

unread,
Mar 12, 2014, 3:42:44 PM3/12/14
to PhistucK, Ojan Vafai, Adam Barth, Darin Fisher, blink-dev
On Wed, Mar 12, 2014 at 3:33 PM, PhistucK <phis...@gmail.com> wrote:
Thank you very much for your work on this, I feel this is a really good addition to the platform (even though it is not generic since it refers specifically to touch input while I can only vaguely imagine a property that handles any kind of old or new input types and their default effects).

Thanks!  Yes, we've talked about maybe having an analogous 'wheel-action' property for trackpad based scrolling, but due to the looser performance constraints it's not nearly as valuable.  We (the pointer events WG) felt that you'd always want something that let you make this decision separately for different types of input (at least direct vs. indirect manipulation), so there wasn't much value in trying to tackle a more general input-agnostic version of this now.  We're happy to discuss further on public-pointer-events though.
 
I wish this would have existed four years ago. :)

And for the sake of correctness -
"manipulation" is not a property as stated (twice) in the intent, but a value of the "touch-action" property.

Yes, sorry - I don't know why I typed property.  Thanks for the correction.

PhistucK

unread,
Mar 12, 2014, 3:51:40 PM3/12/14
to Rick Byers, Ojan Vafai, Adam Barth, Darin Fisher, blink-dev
I guess I was thinking of something along the lines of input-action: auto | list of comma separated (or not) keywords or perhaps named input functions with keywords as parameters. Like input-action: scroll, pan, click; or input-action: touch(auto), pen(scroll), mouse(none); or maybe even piggyback on the pointer-events (hey!) property. This is really fine grained and can accommodate pretty much everything with a single intent.
However, I do not have a concrete idea and understanding of the implementation world or the future needs of the platform to participate in such discussions. The idea mainly came up due to the fact that Microsoft wanted to create a unified model for all of the input events and then added a touch specific CSS property (in the same specification!) which just seems a bit weird to me.


PhistucK

psilocyb...@gmail.com

unread,
Oct 29, 2016, 4:18:53 PM10/29/16
to blink-dev


вторник, 11 марта 2014 г., 7:03:39 UTC+3 пользователь Rick Byers написал:
Reply all
Reply to author
Forward
0 new messages