|Intent to ship: CSS touch-action||Rick Byers||3/10/14 9:03 PM|
Plus the 'manipulation' property currently only in the ED:
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:
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).
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
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
|Re: [blink-dev] Intent to ship: CSS touch-action||Darin Fisher||3/10/14 9:50 PM|
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?
|Re: [blink-dev] Intent to ship: CSS touch-action||Rick Byers||3/11/14 7:57 AM|
On Tue, Mar 11, 2014 at 12:50 AM, Darin Fisher <da...@chromium.org> wrote:
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.
Yes. It disables double-tap zoom but not pinch-zoom.
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.
|Re: [blink-dev] Intent to ship: CSS touch-action||Rick Byers||3/11/14 12:02 PM|
On Tue, Mar 11, 2014 at 10:57 AM, Rick Byers <rby...@chromium.org> wrote:
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.
|Re: [blink-dev] Intent to ship: CSS touch-action||Darin Fisher||3/11/14 12:05 PM|
On Tue, Mar 11, 2014 at 12:02 PM, Rick Byers <rby...@chromium.org> wrote:
Ah, I see. Thanks for clarifying.
OK, thanks for the follow-up. Sounds reasonable to me.
LGTM to ship.
|Re: [blink-dev] Intent to ship: CSS touch-action||Adam Barth||3/12/14 10:33 AM|
|Re: [blink-dev] Intent to ship: CSS touch-action||Ojan Vafai||3/12/14 10:36 AM|
|Re: [blink-dev] Intent to ship: CSS touch-action||Rick Byers||3/12/14 10:39 AM|
|Re: [blink-dev] Intent to ship: CSS touch-action||PhistucK||3/12/14 12:33 PM|
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.
|Re: [blink-dev] Intent to ship: CSS touch-action||Rick Byers||3/12/14 12:42 PM|
On Wed, Mar 12, 2014 at 3:33 PM, PhistucK <phis...@gmail.com> wrote:
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.
Yes, sorry - I don't know why I typed property. Thanks for the correction.
|Re: [blink-dev] Intent to ship: CSS touch-action||PhistucK||3/12/14 12:51 PM|
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.