Add a new property major-overflow-direction to resolve the problem of inconvinent horizontal scrolling in elements(especially vertical writing ones)

[Zhang-Junzhi]

Background(You can read the proposal below by skipping it if you are only interested in the proposal part itself)

A year ago, David Baron mentioned that at a discussion in the CSS WG someone raised the issue that people are hesitant to use vertical writing-mode at the top level of the page(and I think all the horizontally scrollable contents also suffer, regardless of whether it's vertical writing and whether it's at the top level) as most of the users only have a single-direction wheel in their pointing device.

This is a realistic problem we are facing, more than ten years have passed since the first standardized writing-mode came out, but in practical it's still very hard for us to see ANY SINGLE website which uses vertical writing-mode at the its pages' top level. Why? I don't think we can conclude that people aren't interested in vertical writing pages(Think about it: there are about a quarter of the population in the world whose native languages are traditionally vertical writing), I think it's the incovinent horizontal scrolling UX in almost of all browsers which makes the reality.

Unfortunately there is difficulty to solve this kind of issue by browsers themselves without no any standard involving:

Earlier on, I implemented an experimental feature called auto-dir scrolling in Gecko, it's mostly used to horizontalize a vertical wheel scroll to a horizontal scroll when the hovering target only has a horizontal scrollbar but no vertical scrollbar. But the opinions on the feature turned out to vary from person to person, there are people favouring the feature, and there are also people finding it erratic. So, the solution overall doesn't seem to be any better. Part of the reason of the varied thoughts is personal preference, and the more important reason I think is that the necessities of convinent horizontal scrolling are different in different senarios: there are overflowed horizontal contents which are not important and don't need to be read carefully, and there are also overflowed horizontal contents which are very important to be read without which people are unable to comprehend the whole content. For example, the classcial former senario could be some Latin text with lots of lines, and just very few long lines of the text overflowed in the horizontal direction; the classcial latter senario could be some lengthy vertical writing CJK text, and several paragraphs are completely overflowed in the horizontal direction. So it's hard for browsers to distinguish complicated senarios, a standard needs to come out so that the responsibility can handed off to the web developers, so with code, developers would be able to tell the browser how important the convinent horizontal scrolling would be for an element.

---

Proposal

Given the above background, I propose to add major-scroll-direction property in CSS.

The property has the following values:

none
both
vertical
horizontal
auto

The values have the following meanings:

none: This value doesn't give any hint to the user agent as to which direction scrolling is eager for convenience. So no sepcial treatment for scroll input. This value typically indicates the traditional way just as we already have in all browsers.

Take a mouse wheel for example, if the default action of the wheel event scroll is a scroll event, then a vertical wheel is treated as a vertical scroll event, and a horizontal wheel is treated as a horizontal scroll event.

both: This value gives a hint to the user agent that scrollings in either direction are eager for convenience. The user agent should always try its best to provide convenience for the scrolling in either direction when possible.

Take a mouse wheel for example, when the default action of a wheel event scroll is a scroll event, then the behaviour of this value is recommended to be implemented in this way:

1. If the element is only scrollable in one direction, then the default action of any wheel scroll(no matter it's vertical or horizontal) is a scroll event in the only scrollable direction.
2. If the element is scrollable or unscrollable in both directions, then the behaviour is the same as none.

The auto-dir feature mentioned in the Background section above is pretty much the implementation of this value.

horizontal: This value gives a hint to the user agent that scrolling in the horizontal direction is eager for convenience. The user agent should always try its best to provide convenience for the scrolling in horizontal direction when possible.

Take a mouse wheel for example, when the default action of a wheel event scroll is a scroll event, then the behaviour of this value is recommended to be implemented in this way:

1. If the element is only scrollable in the horizontal direction, then the default action of any wheel scroll(no matter it's vertical or horizontal) is a scroll event in the horizontal direction.
2. If the element is scrollable or unscrollable in both directions, or is only scrollable in the vertical direction, then the behaviour is the same as none.

vertical: This value gives a hint to the user agent that scrolling in the vertical direction is eager for convenience. The user agent should always try its best to provide convenience for the scrolling in vertical direction when possible.

Take a mouse wheel for example, when the default action of a wheel event scroll is a scroll event, then the behaviour of this value is recommended to be implemented in this way:

1. If the element is only scrollable in the vertical direction, then the default action of any wheel scroll(no matter it's vertical or horizontal) is a scroll event in the vertical direction.
2. If the element is scrollable or unscrollable in both directions, or is only scrollable in the horizontal direction, then the behaviour is the same as none.

vertical is almost just in theory, actually not of much value in practice. Because the reality is that vertical scrolling is already convinent. But the CSS(as an abstract standard) just doesn't assume the reality. This value is for an imagined pointing device which doesn't support a native convinent vertical scrolling.

auto: If the element is in vertical writing mode(I.e. vertical-rl, vertical-lr, sideways-rl, sideways-lr), the value is computed to horizontal; if the element is in horizontal writing mode(I.e. horizontal-tb), the value is computed to vertical.

major-scroll-direction is an inherited property, and its initial value is none.

---

I am expecting to hearing from your opinions on this proposal.

Thank you.

[Zhang-Junzhi]

I think major-overflow-direction might be a better name than major-scroll-direction.

major-overflow-direction is more abstract than major-scroll-direction. major-overflow-direction covers more than just scrolling, though in reality it's only used to resolve the scrolling problem right now.

[jonjohnjohnson]

Having previously came across @pieter-biesemans https://css-tricks.com/pure-css-horizontal-scrolling/, which turns vertical scrolling on its side, I find this too confusing a solution from a ux perspective, especially in environments like touch screens with such a direct spatial relationship to scrolling interactions. Though I can see your primary example references the coercion of wheel events for horizontal scrolling when there is no current/ancestor vertical overflow. And then there is spatial navigation to account for as well as different implementations of viewport zooming causing navigable "overflow" mid-visit or even reflows that cause overflow of an axis. IMHO it's a worthy problem, but not sure about this solution.

[Zhang-Junzhi]

Thank you for your reply.

I think this issue of the interactions from touch screens can be bypassed if the major-overflow-direction changes the default action at the stage of a wheel event, not at the stage of the scroll event. Because a touch doesn't generate a wheel event.

[Zhang-Junzhi]

Please note that the property is just hinting. It just gives the browser a hint of what direction is more important and the browser needs to focus on the convience in that direction when possible. That's all about the property.

So let's go back to the example of a touchable device, the five values completely mean nothing different in touch-and-touchmove events, because it's known to the browser that horizontal scrolling is just as convinent as vertical scrolling in touch-and-touchmove events so that it doesn't need to make any special treatment for scrolling.

[jonjohnjohnson]

Guessing you'd support the a spacebar to scroll relatively to the major direction? What do you think about mid-visit changes to overflow when both is set? Like the resizing of content or the window so that vertical overflow is created, would you suggest continuing the directional coercion or swapping back? To me, both would seem confusing to a user, if directions change or if now you are scrolling an opposing axis for content in each direction? What about possibly nested scrollers with auto overflow, sometimes affording scrolling, that use each direction? Sincerely interested in your thoughts on how this stuff plays out for what a user would expect.

[Zhang-Junzhi]

It's up to the user agent. I personally think the solution would be making scrolling transactional. So that a continuous scrolling wouldn't suddenly be changed to the other direction. That seems better to me than an untransactional behaviour. Transction applies to both the two examples you raised(I.e. the mid-visit change to overflow, and the nested scrollers with a different scrollable direction).

[jonjohnjohnson]

Then that could still leave users having different scrolling experiences visit to visit when overflow happens due to new sizes of window/content?

[Zhang-Junzhi]

In a mobile touchscreen, the overflow status may be highly variable, however, in that case, the user also tends to touch rather than scroll a wheel, the property does nothing for touch no matter which value it is.

If the overflow status is highly variable on a desktop page(I.e. changable among non-overflow, horizontal overflow , vertical overflow and overflow in both the two directions), then the developer probably shouldn't at all consider using the property in the first place. Using any value other than the initial value none in this case is an unsemantical design on its own.

[jonjohnjohnson]

Somewhat pertinent discussion by the chrome team on implementing their "vertical scroll" policy between frames.

https://bugs.chromium.org/p/chromium/issues/detail?id=853486

[Zhang-Junzhi]

I think this may also be suitable to be put on css-ui-4 label, since it's talking about scrolling behaviour.

[frivoal]

I think this is probably more relevant for css-overflow than for css-ui, but we can decide that later, so I've labeled both.

[Zhang-Junzhi]

To make the long story short, I proposed a new concise alternate #4380.

So I decide to close this issue.