Re: [csswg-drafts] scroll-policy: ease horizontal scrolling by wheel in vertical writing mode (#4380)

Count me in and I think it's important to allow scroll axis to vary independently of the writing mode. My personal website has a multi-column layout for languages in LTR-TTB writing mode, and it should be scrolled horizontally.

There is another issue --- some mice allow four-direction scrolling. If rotating the wheel creates a horizontal scroll, what happens when the user side-clicks the wheel? I think only the wheel rotation interpretation is changed, so side-clicks also cause horizontal scroll. I checked with a Windows 8 app (Wolfram|Alpha) running on Windows 11, and my interpretation is what happens.

Moreover, this should **only affect wheel rotation**, not any other scrolling mechanisms such as panning / pinch-and-pan from touchscreen, touchpad (Apple, macOS), precision touchpad (Windows), (non-precision) touchpad (Windows). For this reason, I think `wheel-scroll-axis` is the better name.

---

Let's try this proposal:

```css
* /* possible values */
{
  /* behavior interpreted by user agent */
  wheel-scroll-axis: auto;

  /* axes dependent on writing-mode */
  wheel-scroll-axis: block;
  wheel-scroll-axis: inline;

  /* absolute axes */
  wheel-scroll-axis: x;
  wheel-scroll-axis: y;

  /* default on all elements except :root */
  wheel-scroll-axis: inherit;
}

/* user agent stylesheet */
:root
{
  wheel-scroll-axis: auto;
}
```

This CSS property should not change how `wheel` events are dispatched in response to wheel rotations --- it's always `deltaY` and positive means the user rotates the wheel towards oneself on Windows (in LTR-TTB and most browsers, this means the content below is made visible).

The reason to not change that is two-fold.

First, it'd be impossible to determine the raw readings if it were changed! Consider the case of wheel rotation and side-clicks. Both will convert to horizontal scroll if `wheel-scroll-axis: x`, but JavaScript authors might want to do different things if they are handling `wheel`.

Second, there's a performance penalty to do that when firing `wheel` events. To determine the rotation axis, the user agent must find the scrolling container targeted by the event, **if the event is to cause a scroll**. However, if the event has a non-passive handler, there's a high chance the wheeling doesn't cause scroll by virtue (or curse) of `preventDefault`. The effort to determine the axis is wasted. (For passive handlers, we don't want the event data to be completely different from non-passive handlers for consistency.)

However, in order to assist JavaScript authors in understanding the consequence of `wheel`. We can propose to add additional (potentially lazily evaluated) properties that computes the action of the user agent if the event is not `prevent`ed`Default`.

---

Appendix:

- A touchscreen refers to ones like those used on iPhone SE/Xs, Windows Phone 7/8/8.1, Surface series PCs (speaking from my personal experience).
  - It is NOT one used on typical ATM screens (e.g., Chase US as of 2020).
- A precision touchpad is one found on MacBook when used with macOS, or one found on Surface series PCs. It supports "continuous" scrolling, panning, pinching.
  - It is NOT one found on MacBook when used with Windows as of 2020 in its default configuration. However, it is if you use [imbushuo/mac-precision-touchpad](https://github.com/imbushuo/mac-precision-touchpad).
- A (non-precision) touchpad is a typical touchpad found on Windows laptops prior to the release of Windows 8. An example is [ThinkPad T400](https://lenovo.fandom.com/wiki/File:T400.jpg).
  - In the picture above, there are two scrollbar image overlays on the bottom/right edges of the touchpad. If you press **hard** on the edge and move your finger along the axis, it causes "jumpy" scrolls, if my memory served me well (this was around 2010).

For touchscreens and precision touchpads, when panning, the user's finger represents action on the canvas --- the user pulls canvas up or down or sideways. The intuitive result is when the user pulls down, the content above is made into view, regardless of writing mode.

For the two-scroll-bar non-precision touchpad like ones used in T400, when pressing and moving, the user expects the action to be done on the corresponding scrollbar. The intuitive result is when the user pulls down, the content below is made into view (this is what happens if you drag the scrollbar downwards), regardless of writing mode.

In all of the cases above, the user interacts with a two-dimensional manner and the result is mapped to viewport canvas or scrollbar, so the axes cannot be switched.

---

Issue to be discussed:

- Suppose when the user rotates the wheel towards oneself, the browser usually brings content below into view. (This assumption is false if you turn on, deep breath, the so-called "natural scroll" on macOS --- which doesn't understand the difference between panning and wheel rotations.) In TTB-RTL (e.g., classical Chinese), what is the most intuitive result when the user rotates the wheel towards oneself?
  - Option 1: To scroll to the left (the content "later" is brought into view). This means we read "usual scroll to the bottom" as "scroll to the block-reading direction".
  - Option 2: To scroll to the right (the content "prior" is brough into view). This means we read "usual scroll to the bottom" as "scroll to the right".

To me, Option 2 is a slight win, but I did have a hard time deciding which is the more intuitive --- because I rarely read classical Chinese typeset TTB-RTL.

There are other [writing directions](https://www.omniglot.com/writing/direction.htm) including bottom-to-top. In an ideal world, research into the intuition of those writing system's users determines the most intuitive action. At the same time, I feel the dominance of Latin script in computing might have affected people's UI intuition.

If we want to do a research, a good starting point seems to be people in Taiwan and Japan. In Taiwan, textbooks are TTB-RTL and a book starts from the "back". So do mangas in Japan.

-- 
GitHub Notification of comment by GeeLaw
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4380#issuecomment-2859394923 using your GitHub account


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

Received on Wednesday, 7 May 2025 17:10:34 UTC