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

adettenb has just created a new issue for https://github.com/w3c/pointerevents:

== [touch actions] handwriting manipulation type to distinguish panning ==
# Summary

Opening an issue to discuss options and alternatives to allow developers control over whether handwriting input should be allowed for elements the user agent supports handwriting input with.

## Introduction

Give developers granular per-document and per-element control over which content should (dis)allow handwriting input for elements which the user agent supports handwriting to text input for.

Earlier created a proposal to introduce an HTML handwriting attribute, however upon review `touch-action` was noted as the preferred mechanism for enabling/disabling touch behaviors.

Currently Android uses the combination of both `pan-x pan-y` as the mechanism to allow handwriting on eligible fields.
However, this means that scrolling and handwriting are tied together, so turning off panning will turn off both handwriting and touch scrolling.

## What this is
* A mechanism for developers to specify whether handwriting, when supported by the user agent, should be allowed.

## What this is not
* A mechanism to detect the availability of handwriting support.
* A mechanism to enable handwriting on elements the user agent doesn't support handwriting for.

## Use Cases

* Document editor that wants to temporarily disable handwriting input while certain tools are selected, to support using a stylus to seamlessly draw, place, or size non-text content overtop an editable text region.
    * Outlook drawing tools with "text pen"
      ![image](https://github.com/user-attachments/assets/c3ba8a8a-c5ec-49fa-a56f-5bf632757afe)
* Application with custom form controls that accept sensitive input, or have a strict but not standardized format that isn't easily input with handwriting to text input.
* Application with custom text inputs or editing experiences that override default browser behaviors by observing and handling input events and editing experiences, doesn't support input method editor (IME) or `composition{start|end|update}` events, or if for any reason the experience designed by website authors doesn't behave as they intend when handwriting input is available.

## Pros
* Matches existing expectations around the `touch-action` CSS property, developers can choose to enable handwriting or not.
* Requires a relatively small code change, both for Chromium implementation and for web developers to control where handwriting should be allowed.
* Allows developers to individually specify whether stylus handwriting or touch scrolling should be enabled.
    * This wouldn't be possible without using preventDefault to bypass handwriting and then manually handle stylus scrolling with something like scrollTo.
    * For example, developers could specify:
        * `touch-action: manipulation` to allow stylus handwriting, and both touch scrolling and touch zoom
        * `touch-action: pinch-zoom handwriting` to allow stylus handwriting and touch zoom, but disallow scrolling
        * `touch-action: pinch-zoom pan-x pan-y` to allow scrolling and touch zoom, but disallow handwriting
## Cons
* ~40% of sites specify `touch-action` and may need treatment to enable handwriting if used in the context of editable text.
    * [Chrome Platform Status (chromestatus.com)](https://chromestatus.com/metrics/css/timeline/popularity/421)
    * Property keywords are opt-in when any are specified (default is opt-out by including all keywords). So sites specifying any keywords other than `auto`, `inherit`, or `manipulation` on editable text or ancestors of them will need to be considered by site developers.
    * i.e., Sites that may want handwriting could unintentionally have it disabled once the experience becomes available, needing to update the site to allow the experience.
    * It's unclear from the chrome status page which keywords are being used or if they're being used in editable context, so not enough information to gauge the full impact.
 
# See also:
* [HTML handwriting attribute explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Handwriting/explainer.md)
* [HTML handwriting attribute Chrome Status](https://chromestatus.com/feature/5186620366782464)
* [HTML handwriting attribute Intent to Prototype](https://groups.google.com/a/chromium.org/g/blink-dev/c/0r_tV6k0NyA)
* [Enable direct pen and touch to have different touch-action behavior](https://github.com/w3c/pointerevents/issues/203)

Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/516 using your GitHub account


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

Received on Wednesday, 4 September 2024 15:45:40 UTC