Re: [pointerevents] `touch-action: none` behavior is intuitive in Firefox, confusing in Chrome. The spec should be clearer. (#387)

@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 https://github.com/w3c/pointerevents/issues/346#issuecomment-759082909, you said that the `pointer-event`s 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).

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 it happens to start on text, this does not automatically mean that 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.

Clearly there are ambiguities here. These APIs are clearly flawed, and you simply close the issue and dismiss them based on things like the structure of specs not mentioning each other.

As an end web developer, this behavior brings down any confidence us end web developers have in the orgs that manage web APIs.

-- 
GitHub Notification of comment by trusktr
Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/387#issuecomment-949596696 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 22 October 2021 12:43:33 UTC