[touch actions] handwriting manipulation type to distinguish panning

[adettenb]

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"
    
• 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)
  • 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
• HTML handwriting attribute Chrome Status
• HTML handwriting attribute Intent to Prototype
• Enable direct pen and touch to have different touch-action behavior

[adettenb]

Migrated to:
w3c/pointerevents#516