New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add explicit control over pinch-zoom to touch-action #29

Closed
RByers opened this Issue Jan 13, 2016 · 23 comments

Comments

Projects
None yet
6 participants
@RByers
Contributor

RByers commented Jan 13, 2016

Consider a common scenario like a long web page with an image carousel . Our guidance to developers would be to put something like 'touch-action: pan-y' on the carousel to permit custom horizontal event handling without disabling scrolling. But this can be an accessibility issue - if the user can pinch-zoom elsewhere in the document, shouldn't they be able to pinch-zoom on the carousel as well?

Edge supports this with the pinch-zoom touch-action token but we omitted that from the spec due to "pinch" being out of scope. But then we ended up referring to "continuous zooming" in normative text anyway. So why not just add a continuous-zoom token too?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 13, 2016

Member

or simply zoom ?

Member

patrickhlauke commented Jan 13, 2016

or simply zoom ?

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jan 13, 2016

Contributor

The problem is we don't want it to imply double-tap zoom (and the associated click delay) ;-)

Contributor

RByers commented Jan 13, 2016

The problem is we don't want it to imply double-tap zoom (and the associated click delay) ;-)

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jan 13, 2016

Contributor

But yeah, simpler names are better. zoom might be OK if we clarify it to be just "continuous zooming" in the spec text (I mean, it's not like I'm that worried about people accidentally DISABLING the click delay ).

Contributor

RByers commented Jan 13, 2016

But yeah, simpler names are better. zoom might be OK if we clarify it to be just "continuous zooming" in the spec text (I mean, it's not like I'm that worried about people accidentally DISABLING the click delay ).

@RByers RByers added the v2-blocking label Feb 4, 2016

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Feb 4, 2016

Contributor

@jacobrossi / @teddink I think this is ultimately a question for you. I think it's important for accessibility that we add something here. Ideally I'd prefer to just match what Edge has already shipped for this: pinch-zoom, even just as a token which we define using the more general spec language about "continuous zooming".

But if using that token is a scope issue and Edge is willing to ship a 2nd token with the same implementation, then I'm fine with either the simple (but possibly confusing) zoom or the more specific (but probably still confusing) continuous-zoom.

Alternately, we could perhaps say that "continuous zooming" is enabled if-and-only-if panning in at least one direction is enabled. Off the top of my head I can't think of any real-world scenarios where you'd want to disable continuous zoom without also disabling panning in all directions. But this is a breaking change, so probably better to be avoided.

Contributor

RByers commented Feb 4, 2016

@jacobrossi / @teddink I think this is ultimately a question for you. I think it's important for accessibility that we add something here. Ideally I'd prefer to just match what Edge has already shipped for this: pinch-zoom, even just as a token which we define using the more general spec language about "continuous zooming".

But if using that token is a scope issue and Edge is willing to ship a 2nd token with the same implementation, then I'm fine with either the simple (but possibly confusing) zoom or the more specific (but probably still confusing) continuous-zoom.

Alternately, we could perhaps say that "continuous zooming" is enabled if-and-only-if panning in at least one direction is enabled. Off the top of my head I can't think of any real-world scenarios where you'd want to disable continuous zoom without also disabling panning in all directions. But this is a breaking change, so probably better to be avoided.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Mar 22, 2016

Contributor

Here's an idea for a term that is both highly descriptive yet refers only to the effect (not the input): "Positioned Incrementally and Naturally Continuously Handled zoom". This is obviously too long for a CSS token, so we'd abbreviate it pinch-zoom. Oh, look at that, Edge already shipped this name, that's a happy coincidence!

Seriously, inventing a new token that's more confusing to developers than the identical feature already shipped elsewhere is dumb. I'm just going to argue for shipping pinch-zoom in blink as a defacto standard, even if it's not in the official spec.

Contributor

RByers commented Mar 22, 2016

Here's an idea for a term that is both highly descriptive yet refers only to the effect (not the input): "Positioned Incrementally and Naturally Continuously Handled zoom". This is obviously too long for a CSS token, so we'd abbreviate it pinch-zoom. Oh, look at that, Edge already shipped this name, that's a happy coincidence!

Seriously, inventing a new token that's more confusing to developers than the identical feature already shipped elsewhere is dumb. I'm just going to argue for shipping pinch-zoom in blink as a defacto standard, even if it's not in the official spec.

@pguerrant

This comment has been minimized.

Show comment
Hide comment
@pguerrant

pguerrant Jun 21, 2016

+1 for adding pinch-zoom to the spec. It is imperative that developers are given a mechanism for disabling browser scroll without affecting the ability to pinch-to-zoom the viewport. This is not only true when using single-directional scrolling but also when disabling native scrolling completely.

A common use case for this is an element that has its own custom handling of the pan-x and pan-y gestures, such as a chart that implements its own panning or rubber-band zoom. In order to prevent native scrolling of its ancestor(s) the element needs to have a touch-action that prevents scrolling in both directions. The way the spec is currently written it is impossible to do this without also disabling zooming of the viewport. In Edge, however, it’s easy - just use touch-action: pinch-zoom double-tap-zoom, and the element is zoomable, but not scrollable.

Name it what you will (pinch-zoom is a fine name) but this functionality must exist for the pointerevents spec to be practically useful. Ideally one should also be able to disable pinch and double-tap zoom separately (rather than just having a single zoom) since they are separate gestures.

I develop javascript frameworks at Sencha, and not having the ability to specify zoomability separately from scrollability on pointerevents devices will be disastrous for our frameworks, as well as any others that use direct manipulation of canvas-based drawings. Fortunately we have not yet had to deal with this because the only browser currently implementing pointerevents (IE/Edge) supports the convenient pinch-zoom and double-tap-zoom touch actions.

pguerrant commented Jun 21, 2016

+1 for adding pinch-zoom to the spec. It is imperative that developers are given a mechanism for disabling browser scroll without affecting the ability to pinch-to-zoom the viewport. This is not only true when using single-directional scrolling but also when disabling native scrolling completely.

A common use case for this is an element that has its own custom handling of the pan-x and pan-y gestures, such as a chart that implements its own panning or rubber-band zoom. In order to prevent native scrolling of its ancestor(s) the element needs to have a touch-action that prevents scrolling in both directions. The way the spec is currently written it is impossible to do this without also disabling zooming of the viewport. In Edge, however, it’s easy - just use touch-action: pinch-zoom double-tap-zoom, and the element is zoomable, but not scrollable.

Name it what you will (pinch-zoom is a fine name) but this functionality must exist for the pointerevents spec to be practically useful. Ideally one should also be able to disable pinch and double-tap zoom separately (rather than just having a single zoom) since they are separate gestures.

I develop javascript frameworks at Sencha, and not having the ability to specify zoomability separately from scrollability on pointerevents devices will be disastrous for our frameworks, as well as any others that use direct manipulation of canvas-based drawings. Fortunately we have not yet had to deal with this because the only browser currently implementing pointerevents (IE/Edge) supports the convenient pinch-zoom and double-tap-zoom touch actions.

@staktrace

This comment has been minimized.

Show comment
Hide comment
@staktrace

staktrace Jun 22, 2016

I'm a little unclear on what it means to allow pinch-zoom without allowing pan-x and pan-y. Most if not all UAs that support pinch-zooming also allow panning around while both fingers are down - would this be disallowed?

Pinch-zooming inherently changes the scroll position, and may do so differently depending on what the focus point of the pinch gesture is. This aspect of pinch-zooming could be considered orthogonal to panning, if we define panning strictly as gestures while a single touch point is down. The way the spec is currently worded, it refers to "scrolling" which could be interpreted as something that implicitly happens during a pinch-zoom, in which case disallowing pan-x and pan-y implicitly disallows pinch-zoom.

(I should probably just try Edge and see what happens, but regardless, it's something that should be explicitly stated if this makes into the spec).

staktrace commented Jun 22, 2016

I'm a little unclear on what it means to allow pinch-zoom without allowing pan-x and pan-y. Most if not all UAs that support pinch-zooming also allow panning around while both fingers are down - would this be disallowed?

Pinch-zooming inherently changes the scroll position, and may do so differently depending on what the focus point of the pinch gesture is. This aspect of pinch-zooming could be considered orthogonal to panning, if we define panning strictly as gestures while a single touch point is down. The way the spec is currently worded, it refers to "scrolling" which could be interpreted as something that implicitly happens during a pinch-zoom, in which case disallowing pan-x and pan-y implicitly disallows pinch-zoom.

(I should probably just try Edge and see what happens, but regardless, it's something that should be explicitly stated if this makes into the spec).

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jun 22, 2016

Contributor

@pguerrant I agree this is important, thanks for the articulation!

@staktrace that's exactly right - once a pinch zoom has started, then all panning/zooming is permitted until the fingers lift. It could certainly be clearer (though possibly not without upsetting lawyers) but I believe it's covered by the definition of touch-action as applying a the "start" of an action.

Contributor

RByers commented Jun 22, 2016

@pguerrant I agree this is important, thanks for the articulation!

@staktrace that's exactly right - once a pinch zoom has started, then all panning/zooming is permitted until the fingers lift. It could certainly be clearer (though possibly not without upsetting lawyers) but I believe it's covered by the definition of touch-action as applying a the "start" of an action.

@pguerrant

This comment has been minimized.

Show comment
Hide comment
@pguerrant

pguerrant Jun 22, 2016

@staktrace @RByers to clarify, yes some panning can occur during a pinch-zoom action, but it can only change the scroll position of the viewport, and does not affect the scroll position of any elements below it that are scrollable by virtue of having overflow:auto or overflow:scroll, i.e. no "scroll chaining" occurs as does during a normal scroll. As such, I think it makes sense to view such panning as part of the pinch-zoom touch action. This is separate from pan-x and pan-y which control the ability to single-touch scroll any scrollable element on their respective axes. At least that is how it is currently implemented in IE/Edge.

pguerrant commented Jun 22, 2016

@staktrace @RByers to clarify, yes some panning can occur during a pinch-zoom action, but it can only change the scroll position of the viewport, and does not affect the scroll position of any elements below it that are scrollable by virtue of having overflow:auto or overflow:scroll, i.e. no "scroll chaining" occurs as does during a normal scroll. As such, I think it makes sense to view such panning as part of the pinch-zoom touch action. This is separate from pan-x and pan-y which control the ability to single-touch scroll any scrollable element on their respective axes. At least that is how it is currently implemented in IE/Edge.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jun 22, 2016

Contributor

@pguerrant I agree completely - thanks!

Contributor

RByers commented Jun 22, 2016

@pguerrant I agree completely - thanks!

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Jul 6, 2016

Member

We now have a bug filed against jQuery UI because of the pinch zoom behavior not working inside a draggable element that uses touch-action: none: https://bugs.jqueryui.com/ticket/14993

Member

scottgonzalez commented Jul 6, 2016

We now have a bug filed against jQuery UI because of the pinch zoom behavior not working inside a draggable element that uses touch-action: none: https://bugs.jqueryui.com/ticket/14993

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 6, 2016

Contributor

Yes, I think this issue is bigger than just direction-specific scenarios. I think there are scenarios like this where you really want touch-action: pinch-zoom instead of touch-action: none. I'll put up a PR that attempts to add this.

Contributor

RByers commented Jul 6, 2016

Yes, I think this issue is bigger than just direction-specific scenarios. I think there are scenarios like this where you really want touch-action: pinch-zoom instead of touch-action: none. I'll put up a PR that attempts to add this.

@RByers RByers self-assigned this Jul 6, 2016

@RByers RByers changed the title from Touch-action doesn't permit direction-specific scroll AND pinch-zoom to Add explicit control over pinch-zoom to touch-action Jul 6, 2016

@teddink

This comment has been minimized.

Show comment
Hide comment
@teddink

teddink Jul 6, 2016

Great - thanks Rick. We are still having discussions with our friends that have Esquire in their titles. Hopefully we will have more insights by the face to face in a couple of weeks. We will also have to take a look at our current charter, which has some exclusions related to this topic in it today.

teddink commented Jul 6, 2016

Great - thanks Rick. We are still having discussions with our friends that have Esquire in their titles. Hopefully we will have more insights by the face to face in a couple of weeks. We will also have to take a look at our current charter, which has some exclusions related to this topic in it today.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 6, 2016

Contributor

Understood. I'll do my best to word this in a way that doesn't formally invoke anything new.

Contributor

RByers commented Jul 6, 2016

Understood. I'll do my best to word this in a way that doesn't formally invoke anything new.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 6, 2016

Contributor

Note that the existing support in Edge doesn't appear to work the way I'd expect to address the above issues. Filed this bug.

Contributor

RByers commented Jul 6, 2016

Note that the existing support in Edge doesn't appear to work the way I'd expect to address the above issues. Filed this bug.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 27, 2016

Contributor

Discussed at the hackathon - the bug was mobile-specific, works fine in desktop.

Contributor

RByers commented Jul 27, 2016

Discussed at the hackathon - the bug was mobile-specific, works fine in desktop.

@RByers RByers removed the v2-blocking label Sep 7, 2016

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Sep 7, 2016

Contributor

Agreed in PEWG call today that this doesn't need to be v2-blocking. Implementations are expected to have this as "a defacto standard" based on existing Edge support. Spec status is secondary to that.

Contributor

RByers commented Sep 7, 2016

Agreed in PEWG call today that this doesn't need to be v2-blocking. Implementations are expected to have this as "a defacto standard" based on existing Edge support. Spec status is secondary to that.

@staktrace

This comment has been minimized.

Show comment
Hide comment
@staktrace

staktrace Sep 23, 2016

FTR the comments above address my concerns, so +1 for pinch-zoom from me as well.

staktrace commented Sep 23, 2016

FTR the comments above address my concerns, so +1 for pinch-zoom from me as well.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Sep 23, 2016

Contributor

Also, as discussed in the web-platform-test meeting at TPAC, "defacto" tests are welcomed in WPT (as long as they are clearly labeled somehow as reflecting defacto interop, not some spec). So (unless there is objection here) we can take the tests @dtapuska is landing in blink and move them to web-platform-test/pointerevents (eg. with a 'defacto-' filename prefix).

Contributor

RByers commented Sep 23, 2016

Also, as discussed in the web-platform-test meeting at TPAC, "defacto" tests are welcomed in WPT (as long as they are clearly labeled somehow as reflecting defacto interop, not some spec). So (unless there is objection here) we can take the tests @dtapuska is landing in blink and move them to web-platform-test/pointerevents (eg. with a 'defacto-' filename prefix).

@teddink

This comment has been minimized.

Show comment
Hide comment
@teddink

teddink Sep 27, 2016

Sounds reasonable to me.

teddink commented Sep 27, 2016

Sounds reasonable to me.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Dec 20, 2016

Contributor

It sounds like we're unlikely to get permission to add this here.

For now I've defined it in the compat spec - whose whole purpose is to describe the real world of implementations when (for whatever reason) the official specs do not. I propose adding a note referencing the compat spec from the PE sepc (without needing to say why).

If we do that, then I'd be OK calling this issue resolved for now.

Contributor

RByers commented Dec 20, 2016

It sounds like we're unlikely to get permission to add this here.

For now I've defined it in the compat spec - whose whole purpose is to describe the real world of implementations when (for whatever reason) the official specs do not. I propose adding a note referencing the compat spec from the PE sepc (without needing to say why).

If we do that, then I'd be OK calling this issue resolved for now.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 23, 2016

Member

SGTM and as #162 is merged, i'll close this.

Member

patrickhlauke commented Dec 23, 2016

SGTM and as #162 is merged, i'll close this.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Dec 23, 2016

Contributor

Thanks. Yeah this isn't idea but I think it's likely to be about as good as it gets. We've also updated the MDN entry to describe pinch-zoom and also reference the compat spec. So hopefully there's little risk of developers not being aware of this option due to us not being able to write it down in the official spec.

Contributor

RByers commented Dec 23, 2016

Thanks. Yeah this isn't idea but I think it's likely to be about as good as it gets. We've also updated the MDN entry to describe pinch-zoom and also reference the compat spec. So hopefully there's little risk of developers not being aware of this option due to us not being able to write it down in the official spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment