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?
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.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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.