Re: [csswg-drafts] Setting the primary scrolling direction for a scroll container (#10060)

Coming from #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.

I like the concept of 1D and 2D scroll devices.

The distinction of 1D and 2D scroll device should be as follows: if the device gives equal access to two orthogonal directions of scroll, then it's a 2D scroll device, otherwise it's 1D.

- Mice whose wheel supports rotating and side-clicks: The rotate is much easier to access, provides finer scroll progression, than side-clicks (one click is a fixed, somewhat large scroll, and using clicks to scroll is much less smooth than wheels, even for very coarse-grained wheels). Therefore, this is a 1D scroll device.
- Precision touch pad, touch screen, non-precision touch pad with bottom & right edges for scrolling (see #4380 for reference photo of ThinkPad T400): These are 2D scroll devices.

---

Attempted proposal, combined with new names:

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

  /* axes dependent on writing-mode */
  primary-overflow-axis: block;
  primary-overflow-axis: inline;

  /* absolute axes */
  primary-overflow-axis: x;
  primary-overflow-axis: y;

  /* default on all elements except :root */
  primary-overflow-axis: inherit;
}

/* user agent stylesheet */
:root
{
  primary-overflow-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 `primary-overflow-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`.

---

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/10060#issuecomment-2861483256 using your GitHub account


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

Received on Thursday, 8 May 2025 03:05:03 UTC