Re: [pointerevents] `touch-action: none` definition is too vague (#276)

I believe `touch-action:none` should prevent _all_ default interaction (as if `preventDefault()` was called for all cases), and the developer will 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:

I think it would be very intuitive for `touch-action:none` to prevent _all_ native interactions. The spec says that `touch-action:none` applies to

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

One can also present the case that selecting text (at least with a mouse) involves the exact same motion as a panning gesture (just that it will select text instead of panning).

Based on 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 for all forms of pointers.

This appears to already be the case in Firefox, as far as I have experienced. 

The behavior in Chrome is confusing and not intuitive, and makes development using Pointer Events difficult and error prone; it took a while to realize what was happening in the above Chromium bug report.

The pattern of Point Event handling in the bug's example is works intuitively as expected in Firefox, just not Chrome. To make it work in Chrome, the pattern has to be entirely refactored. The appearance of the `pointercancel` events is unexpected.

GitHub Notification of comment by trusktr
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Friday, 18 June 2021 03:22:34 UTC