You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's incorrect to consider the touch-action values only up to the nearest
ancestor that supports ANY default touch behavior. Eg. in Edge you can
disable double-tap to zoom across an entire page (including any iframes
or other scrolling elements) by applying 'touch-action: manipulation' to
the html element. See https://jsbin.com/tipure/ and https://jsbin.com/jucuna.
This is issue #19.
This change also moves the core processing model details up to
above the specific value definitions to make it easier to follow
without getting lost in all the value-specific notes.
It's incorrect to consider the touch-action values only up to the nearest
ancestor that supports ANY default touch behavior. Eg. in Edge you can
disable double-tap to zoom across an entire page (including any iframes
or other scrolling elements) by applying 'touch-action: manipulation' to
the html element. See https://jsbin.com/tipure/ and https://jsbin.com/jucuna.
This is issue w3c#19.
This change also moves the core processing model details up to
above the specific value definitions to make it easier to follow
without getting lost in all the value-specific notes.
@jacobrossi I agonized over this text to try to be precise while also avoiding specific gesture details. After an hour, this was the best I could come up with. Do you think it's an improvement?
I'd like to add a web-platform-test case for this, but since which elements support "non-continuous zooming" is out of scope of the spec, I guess I can't - right? Hopefully the jsbin demos are good enough.
In particular, here's the relevant text (since I also foolishly shifted some things around in the same CL):
A touch behavior is supported if allowed by the touch-action properties of all elements between the hit tested element and it's nearest ancestor with the default touch behavior (including both the hit tested element and the element with the default touch behavior).
I talked with @jacobrossi offline and he agreed that (while not perfect) this was definitely a step in the right direction and we should just land it and continue to iterate.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It's incorrect to consider the touch-action values only up to the nearest
ancestor that supports ANY default touch behavior. Eg. in Edge you can
disable double-tap to zoom across an entire page (including any iframes
or other scrolling elements) by applying 'touch-action: manipulation' to
the html element. See https://jsbin.com/tipure/ and https://jsbin.com/jucuna.
This is issue #19.
This change also moves the core processing model details up to
above the specific value definitions to make it easier to follow
without getting lost in all the value-specific notes.