touch-action: none behavior is intuitive in Firefox, confusing in Chrome. The spec should be clearer.

[trusktr]

(Continuing from #276)

I believe touch-action:none should prevent all default interaction (as if preventDefault() 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:

1. The spec says that touch-action:none applies to

   interactions (which are not limited to touch, despite the property's name).

2. One can present the case that selecting text involves the same motion as a panning gesture (just that it will select text instead of panning): pointer down, pointer move, pointer up.

Based 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 of touch-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 handle pointercancel. It's a cryptic topic. Firefox made a good choice to prevent all interaction when touch-action:none is set: it makes things straight forward and simple.

[trusktr]

Additionally, maybe there should be a new touch-action: text; option (or touch-action: select;, naming is bike-sheddable), and that one should behave like what Chrome currently does (though I'm not sure that's what is even happening in Chrome, as I don't see any text selection highlight indication).

none for touch action should really mean there are none handled by the browser, regardless of pointer type.

[patrickhlauke]

if this is purely about disabling text selection... https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

[patrickhlauke]

also, on the more generalised

I believe touch-action:none should prevent all default interaction (as if preventDefault() was called for all cases)

this would then kill any click/tap interactions on things like buttons and links, which is undesirable (otherwise as soon as touch-action:none is used, authors would have to completely reengineer every interaction themselves, which was not the point). it may suit your very specific use case to do that, but not the general situation we're trying to address.

[patrickhlauke]

Closing this for now, as the original intent of touch-action - as recently clarified and further reinforced in the spec text - was to only apply to controlling/suppressing panning (of the viewport) and scrolling (of the viewport) gestures. text selection is not a panning gesture, as is does not pan the viewport.

[trusktr]

@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 pointer-events property has nothing to do with JS PointerEvent, which essentially means you dismiss any existing problem based solely on the fact that two separate papers (specs) may not interact with each other (or some similar criteria based merely on spec structure).

This is blatantly wrong from what "pointer events" means to any web developer. Both of those concepts go hand in hand.

The CSS pointer-events property has direct impact on how the JS PointerEvent API behaves, therefore the two are directly related.

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?

this would then kill any click/tap interactions on things like buttons and links, which is undesirable (otherwise as soon as touch-action:none is used, authors would have to completely reengineer every interaction themselves, which was not the point). it may suit your very specific use case to do that, but not the general situation we're trying to address.

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?

Closing this for now, as the original intent of touch-action - as recently clarified and further reinforced in the spec text - was to only apply to controlling/suppressing panning (of the viewport) and scrolling (of the viewport) gestures. text selection is not a panning gesture, as is does not pan the viewport.

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.

[trusktr]

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.

I believe touch-action:none should prevent all default interaction

What about new options for touch-action like prevent-all (more powerful than none, actually stop everything, another name may be user-defined), tap-only (movements are ignored, so no panning or text selection, clicks work), movement-only, etc?

Maybe something like touch-move-threshold can take a number. If movement is less than threshold, then touch-action: tap-only may allow taps, and a default is spec'd. Etc.

Any other ideas?

[patrickhlauke]

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 user-select:none to the <lume-node> - as was suggested early on in this thread.

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 user-select is the already standardised solution here, i don't see what the advantage would be to also duplicate this same behaviour specifically in touch-action as well.

as for futher features/values for touch-action like a threshold, suggest these be filed as separate suggestions.

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.

[trusktr]

@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 touch-action:none would simply do what it seems to imply: that no built-in touch actions will happen (regardless if that means I'm selecting something or not), and that I should implement touch behavior myself. This would be clear and intuitive.

---

What if there was a new option like touch-action: selection so that touch-action: none obviously doesn't include it? Etc? Should we open a new issue for some sort of extension to make this more intuitive? Or are you averse to that?