Re: [pointerevents] [touch actions] handwriting manipulation type to distinguish panning (#516)

Following the panning rules seems to be a good idea, as the `handwriting` keyword will be replacing the current unofficial heuristic that requires `pan-x pan-y` to enable handwriting.

Another angle this could be tackled from is to use writable elements as panning uses scrollable elements, so the spec would look something like this:

> * A direct manipulation interaction for **panning** is supported if it [conforms](https://www.w3.org/TR/pointerevents/#dfn-conforming-touch-behavior) to the touch-action property of each element between the hit tested element and its nearest inclusive ancestor that is a [scroll container](https://www.w3.org/TR/css-overflow-3/#scroll-container) (as defined in [[CSS-OVERFLOW-3](https://www.w3.org/TR/pointerevents/#bib-css-overflow-3)]).
> * A direct manipulation interaction for **handwriting** is supported if it [conforms](https://www.w3.org/TR/pointerevents/#dfn-conforming-touch-behavior) to the touch-action property of each element between the hit tested element and its nearest inclusive ancestor that is an _editable element_ (probably taking some definition from [here](https://www.w3.org/TR/2008/WD-html5-20080610/editing.html)).

This way, we can have handwriting rules that are independent on whether or not an element is scrollable, which on the surface level at least seem unrelated. Some pros and cons for this approach:

**Pros:**
* Greatly minimizes the amount of existing scenarios we will remove handwriting for, practically minimizing this backwards compatibility concern (I speculate that much more than making handwriting follow the panning rules).
* We aren't creating an arbitrary unprecedented rule, just taking what exists for panning and adapting it for this new use case.
* Makes scrolling and handwriting independent from each other.

**Con:**
* Adds one more rule that developers would have to take into consideration if they want no touch actions in their web pages. Not only would they have to explicitly set `touch-action: none;` for scrollable containers, but also for text editable elements. For example:
```
<style>
body {
    touch-action: none;
}
</style>
<div style="overflow: auto;background-color:lightblue;height:300px;width:300px;touch-action: auto;">
    <div style="touch-action: auto;width:500;height:500;" contenteditable="true">
        This element can pan due to the scroller allowing it, but it wouldn't have handwriting.
    </div>
</div>
<input type="text">/*this input would have handwriting, but no panning*/</input>
```
In this page, if authors don't want any touch action in the entire page to be consumed by the UA they would have to add touch-action: none; in both the scrollable div and the input.

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


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

Received on Tuesday, 11 February 2025 19:52:02 UTC