-
Notifications
You must be signed in to change notification settings - Fork 33
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
touch-action: none
behavior is intuitive in Firefox, confusing in Chrome. The spec should be clearer.
#387
Comments
Additionally, maybe there should be a new
|
if this is purely about disabling text selection... https://developer.mozilla.org/en-US/docs/Web/CSS/user-select |
also, on the more generalised
this would then kill any click/tap interactions on things like buttons and links, which is undesirable (otherwise as soon as |
Closing this for now, as the original intent of |
@patrickhlauke As a WCAG member and web evangelist, I'm surprised you don't think there is a problem here, and that you closed the issue. In #346 (comment), you said that the This is blatantly wrong from what "pointer events" means to any web developer. Both of those concepts go hand in hand. The CSS This sort of dismissive mindset is what makes specs worse, makes the web worse, and does not help evangelize the web. Why not fight for bringing more clarity to these specs and making web APIs better and more intuitive? Why do you prefer to dismiss problems?
And? You're not willing to help figure out how to improve this situation? You don't wish to propose even the seed for an idea, but prefer to close the issue?
The term "touch action" is very vague compared what you describe. A user performing a panning gesture can easily (and randomly) perform this gesture on top of, or not on top of, text. If a gesture happens to start on text, this does not automatically mean that the user was not attempting a pan gesture. The movement of panning a viewport, and the movement of selecting text, are essentially identical. Some browsers require a long-press first. Note, I have not performed long presses when testing any of these issues I have mentioned and encountering problems. Clearly there are ambiguities here. These APIs are clearly flawed, and you simply close issues and dismiss them based on silly things like the structure of specs. As an end web developer, this behavior brings down any confidence us end web developers have in the orgs that manage web APIs. |
I hope you can see my frustration as an end user of web APIs @patrickhlauke. Also the fact that Firefox doesn't have the issue but Chrome does could be a valid reason not to close this.
What about new options for Maybe something like Any other ideas? |
going right back to the original demo https://stackoverflow.com/questions/65694472/google-chrome-bug-why-do-pointerover-and-document-pointerup-events-not-fire-s the problem is solved it seems by adding the fact that firefox chooses to apparently also suppress user selection in this case while chrome doesn't is their choice, but it's outside of what's currently spec'd in pointer events. and as as for futher features/values for a further suggestion: it's generally counter-productive to try to garner support for your idea by first mentioning how surprised you are that a person isn't just jumping at your idea, and having a go at them for not putting in the effort to do your homework. |
@patrickhlauke You're looking at this from a technical point of view, but you aren't looking at if from an end-user point of view and what an end user would find intuitive (or if you are, you're not considering it important enough). Thanks for pointing out a workaround. But, if there's nothing to select, why is selection happening? That's counter intuitive. Questions like these could be eliminated if an API like What if there was a new option like |
(Continuing from #276)
I believe
touch-action:none
should prevent all default interaction (as ifpreventDefault()
was called for all cases), and developers should handle all interaction inside the container, regardless if from fingers, a mouse, or anything else.Firefox appears to do what I just described, but Chrome does not. This led me to believe there was some sort of bug in Chrome, and even Chrome engineers did not know what was happening, which shows how confusing the problem is:
https://bugs.chromium.org/p/chromium/issues/detail?id=1166044
I think it would be very intuitive for
touch-action:none
to prevent all native interactions for all pointers.A couple key points:
touch-action:none
applies toBased on the previous two points, and the fact that the purpose of the Pointer Events API is to unify handling of pointers regardless if they are fingers, pens, mouse cursors, trackball cursors, or anything else, it would make sense for the
touch-action
property (especially the behavior oftouch-action:none
) to apply to all gestures (panning and text selection are the same gesture) for all forms of pointers. Essentially the developer should decide exactly what pointer interaction will do, by implementing handling using Pointer Events.The pattern of Pointer Event handling code seen in the bug's example works intuitively as expected in Firefox, which is great: no unexpected surprises.
The behavior in Chrome is confusing and not intuitive, and makes development using Pointer Events difficult and error prone; it took a while for anyone, including the Chrome team, to realize what was happening in the above Chromium bug report. The occurrence of the
pointercancel
events was totally unexpected.To make it work in Chrome, the pattern has to be refactored.
Lastly, once someone knows that
pointercancel
is getting in the way (in Chrome-based browsers), there is hardly any information (in particular, no examples or articles) on how to handlepointercancel
. It's a cryptic topic. Firefox made a good choice to prevent all interaction whentouch-action:none
is set: it makes things straight forward and simple.The text was updated successfully, but these errors were encountered: