Stricter user gestures for touch

[RByers]

Building on #12, no browser does a great job of this today for touch input. The fundamental problem is that, unlike mouse, the gesture for scrolling is ambiguous - may or may not be a substantial interaction with the page (eg. consider a sliding toggle switch).

Problem details and a specific proposal are here

[singhvijayy]

Will touchstart, touchmove and touchend be supported as triggers for starting, continuing and ending a path on a canvas element?

[RByers]

Will touchstart, touchmove and touchend be supported as triggers for starting, continuing and ending a path on a canvas element?

There shouldn't be any change here for anything to do with canvas (drawing on a canvas never requires a "user gesture"). But such code could be affected by #18 if the touch listeners are on the document and aren't already using touch-action: none to declaratively disable touch scrolling over the canvas.

[toddreifsteck]

@RByers Is this issue intended to cover everything within that proposal document? I'm asking because that document seems to cover a few somewhat separate use-cases/goals/possible implementation details.

[RByers]

@toddreifsteck sorry I missed the above. Yes this issue covers figuring out what the precise heuristics should be for touch, and getting them standardized.

[domenic]

I believe this issue is now solved, in the HTML Standard. In particular, it's covered by the activation triggering input event definition, which was recently settled (with tests!) in whatwg/html#7248.

There's still a concern from @flackr at whatwg/html#7341 about how pointer vs. touch events are treated differently, but we can track that over on the HTML Standard repository. As such, we'll close this issue, as part of the larger project of archiving this repository (see #72).