Should `touch-action` support logical directions like `pan-inline` / `pan-block`?

[xfq]

This question was prompted by the Pointer Event issue at https://github.com/w3c/pointerevents/issues/505

What is touch-action?

Imagine you have an element on a webpage (like a map or a list) that you can interact with using touch. The touch-action CSS property tells the browser how to handle finger swipes on that element:

• touch-action: auto; (the default): The browser tries to figure out if you're scrolling or zooming the page.
• touch-action: none; : The browser doesn't handle swipes for scrolling/zooming.

Directions in touch-action

There are some values like pan-left, pan-right, pan-up, and pan-down. These tell the browser: "Only handle swipes for scrolling in this specific direction."

Example: imagine a list that's scrolled all the way to the top. The developer might set touch-action: pan-down; on it. This means:

• If the user swipes down (to scroll down the list), the browser handles the scrolling.
• If the user swipes up (trying to scroll past the top), the browser doesn't scroll.

The Problem: Physical vs. Logical Directions

These pan-left, pan-right, pan-up, pan-down values are based on the physical screen directions.

We are considering adding logical values like:

• pan-inline: Allow scrolling only in the direction text flows (e.g., right for LTR horizontal, left for RTL horizontal).
• pan-block: Allow scrolling only in the direction perpendicular to text flow (e.g., down for horizontal text).
• Maybe also pan-inline-reverse and pan-block-reverse for when content is scrolled to the end.

These logical values would automatically adapt to the element's direction (ltr/rtl) and writing mode (horizontal/vertical).

My question is: is adding these logical values (pan-inline, pan-block, etc.) important for authors working with RTL languages?

---

Alternatives: authors could achieve the same result without these new values. They could:

1. Write separate CSS rules using direction selectors (like :dir(rtl)). For example:

   .myList:dir(ltr) { touch-action: pan-right; }
   .myList:dir(rtl) { touch-action: pan-left; }
   

2. Set the touch-action property using JavaScript after checking the element's direction.

[shadeed]

Hello, author of the RTL styling guide here.

Since the direction of scrolling changes based on the page direction, I'd vote to enable pan-inline and pan-block.

An example I thought of is having a section with horizontal scrolling. In LTR, the user will pan to the left to view more content. In RTL, they will pan to the right side. Having pan-inline will solve that nicely.

[ebraminio]

A multi language ready UI platform indeed uses logical directions for swipe and drags, for example in Android, only by the change of language and direction you'll get this, right to left swipe for drawer open in RTL

https://github.com/user-attachments/assets/7db6df26-a1df-4c0a-925e-74fbee091265

and left to right swipe for drawer open in LTR

https://github.com/user-attachments/assets/0f9dee19-4d31-467a-8306-b90b3591e6e3

[patrickhlauke]

For context, I do have a fairly naive proposed addition for logical values here https://github.com/w3c/pointerevents/pull/496 - so any ideas/suggestions there are welcome. As per https://github.com/w3c/pointerevents/issues/505#issuecomment-2288778089 we (PEWG) weren't sure about adding this to the proposed Pointer Events Level 3, or whether to defer it to the next version of the spec

[nico3333fr]

Hey there, heavy user of CSS logical props :)

I also vote to enable pan-inline and its friends: this might solve some UI cases we have with horizontal scrolling and other cases... being more future-proof.