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

I'm on the fence about restoring the `handwriting` bit for nested scrollable areas.
I think it might be better to scope restoring the `handwriting` bit when entering a nested document instead, similar to `pinch-zoom`.

The main appeal I see for restoring the `pan` bits is the keyword is directly tied to the behavior enabled by `overflow`. It encourages developers to disable scrolling for each context that needs to. A developer may want to disable touch scrolling for the main document, but likely wouldn't want to disable scrolling for all widgets/modules/etc. that become scrollable when the user resizes the window or a portion of the document. A scenario that comes to mind is a richly editable infinite canvas or chat application with nested code blocks or something, where the author wants to handle panning/scrolling/resizing content themselves, but when a nested textbox becomes scrollable from user actions (entering text, resizing content/window) then touch scrolling would work for that content unless the developer specified otherwise (e.g., for a more natural text editing experience; selection or caret placement).

However, adding the `handwriting` keyword is meant to decouple the behavior from `pan` since handwriting behavior isn't dependent on content being scrollable or related to `overflow` beyond taking precedence over (suppressing) scrolling when handling stylus events. I worry this could make it more difficult or impossible to prevent handwriting for some widgets containing `overflow` content. I need to think about this some more and experiment a bit, but I think restoring the `handwriting` bit based on either `overflow` or which document the element belongs to may make it impossible  for developers to disable handwriting for editable text fields within native Shadow DOM controls?

I'm also curious what the behavior should be for OOP `<iframe>`?
- Should that be the responsibility of the embedder or the host content?
- Should developers be able to disable `handwriting` for an `<iframe>`:
    - ... implicitly through inheritance
    - ... explicitly by specifying `touch-action` on the outer `<iframe>` element
    - ... or should that be at the discretion of the content being embedded?

For OOP `<iframe>`'m I leaning towards the last point, effectively following the example of `pinch-zoom` and scoping `handwriting` to the nearest containing document. It might be desirable to allow embedders to explicitly override this for the nested document with `<iframe style="touch-action: none;">` or something like that, but the existing rules for `pan` and `pinch-zoom` allow the nested document to restore those bits.

---

I think this is worth pursuing though as an experiment. I think @gastonrod's recent histogram CL will help understand the impact for these kinds of scenarios.

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


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

Received on Saturday, 22 February 2025 02:04:29 UTC