Setting the primary scrolling direction for a scroll container

[Zhang-Junzhi]

Currently, almost all UAs assume the vertical direction is the first-class scrolling direction, so that UAs set the default action of a pure wheel event to scrolling the content vertically, while setting the default action of a wheel event with an additional key(typically Shift Key) to scrolling the content horizontally.

That's a reasonable assumption for a page in horizontal writing mode. A page in vertical writing mode, however, is another story, which is much more likely to overflow horizontally.

If we can set an element's primary scrolling direction, then an UA knows that it can set the default action of the pure wheel event to scrolling the content horizontally, while setting the default action of a wheel event with an additional key to scrolling the content vertically.

Also, there are two vertical writing modes: vertical-rl and vertical-lr. It is worth suggesting UAs to logically "convert" scrolling direction.

[Zhang-Junzhi]

Just as a personal opinion:

I personally prefer the concept of overflow, instead of scroll for CSS, for example, I would prefer a property named primary-overflow-direction over primary-scroll-direction:

html {
    writing-mode: vertical-rl;
    primary-overflow-direction: horizontal;
}

Because overflow is a more "style-oriented" name, although I started the topic using the concept of scroll, for the purpose of intuitively describing the issue.

A primary overflow direction is only suggestive information, it only tells an UA which direction is expected to be scrolled only by the user (or at least to be scrolled far more frequently than the other direction). The UA then takes advantage of the knowledge, and improves UX as far as possible, for example, by "converting" the default actions of wheel events for a mouse with one single directional wheel.

[Zhang-Junzhi]

Further argument: Why is this feature necessary for CSS? What's the problem if a JavaScript developer programmatically implements such a feature?

1. Performance issue. Although JavaScript developers are absolutely able to change the default action of a wheel event for vertical-writing pages, but they have to set the wheel event's passive option to false, in order to be able to call preventDefault to prevent the default action, and then write their own action code. Unfortunately, turning off passive mode results in a very big performance loss.

2. Ugly coupling. Also, this couples style with event handling, making code hacky.

3. Uncertain consequence. Things become even worse if you consider the default action of a wheel event is implementation-specific, and may vary from UA to UA. By blindly preventing the default action of a wheel event, the developer is doing something at risk of messing things up.

[fantasai]

I think UAs should be doing this automatically, based on the principal writing mode. So I guess there's a few questions:

• Do implementers agree with this interpretation?
• Should we clarify expectation this in the spec somehow, e.g. in an example or a note?
• Is there a way to write a WPT test for this?
• Are there bugs filed against implementations for this?

[Zhang-Junzhi]

I think UAs should be doing this automatically, based on the principal writing mode.

It's absolutely reasonable to do this automatically based on the principal writing mode. However, as an alternate solution, I would also like to further introduce just my two cents on adding a new property:

While what this issue mainly aims to handle is about vertical writing mode, there might also be cases where it's desirable for pages even when it's principal writing mode is horizontal. For example, a horizontal-tb page can use the property if it contains a bunch of extremely wide cityscape pictures:

<div style="primary-overflow-direction: horizontal; overflow: auto">
    <!--a bunch of extrememly wide cityscape pictures-->
    <picture ...>...</picture>
    <picture ...>...</picture>
    <picture ...>...</picture>
    ...
</div>

* Are there bugs filed against implementations for this?

Yes, there're at least bugs filed for this kind of issues, as far as I know, on bugzilla.mozilla.org:

Years ago, the issue was mentioned by David Baron, and then I implemented autodir feature for Firefox.

later on, the Firefox Desktop team also utilises the autodir feature to improve UX.

Unfortunately, the big disadvantage of autodir is that it's not a CSS thing, so it's unaware of any element's style. Turning autodir on by default would mean pages all over the world that contain any horizontally scrollable elements could be affected. So Firefox had to turn autodir off by default.

Things are much better if we solve this issue with CSS: the issue that autodir couldnot resolve can be resolved perfectly by CSS: Because with CSS, we can selectively affect pages or elements according to it's style(Either automatically based on the principal writing mode, as you said, or manually set using a new property, as I said).

[fantasai]

Turning autodir on by default would mean pages all over the world that contain any horizontally scrollable elements could be affected.

That seems... expected?

So Firefox had to turn autodir off by default.

Can you explain why?

[SebastianZ]

Turning autodir on by default would mean pages all over the world that contain any horizontally scrollable elements could be affected.

That seems... expected?

Not necessarily. Imagine an article with a horizontal image gallery. If the reader is only interested in the article text, it would be surprising/annoying for them if while scrolling down the scroll direction suddenly changed within the image gallery.

Sebastian

[Zhang-Junzhi]

Turning autodir on by default would mean pages all over the world that contain any horizontally scrollable elements could be affected.

That seems... expected?

So Firefox had to turn autodir off by default.

Can you explain why?

@SebastianZ gave a good example why autodir has to be turned off by default: Because autodir is unware of CSS style, so it will blindly apply to ANY elements if they are horizontally scrollable.

On the contrary, with CSS, we can selectively affect pages or elements where the developer is pretty sure the user will be eager to scroll horizontally(e.g. a page with vertical principal writing mode, or a bunch of extremely wide cityscape pictures on a city fan website the user will definitely be interested in). This is where a CSS solution will go beyond autodir.

[fantasai]

Because autodir is unware of CSS style, so it will blindly apply to ANY elements if they are horizontally scrollable.

I don't understand. Wasn't the behavior taking into consideration both overflow and writing-mode? These are both CSS properties.

Not necessarily. Imagine an article with a horizontal image gallery. If the reader is only interested in the article text, it would be surprising/annoying for them if while scrolling down the scroll direction suddenly changed within the image gallery.

Suppose the gallery is vertical instead of horizontal. Why should that be different? Either the user wants to scroll through the image gallery or they don't. Laying out the gallery horizontally vs vertically shouldn't make a difference to whether scroll events are sent to the gallery or the main page.

[Zhang-Junzhi]

I don't understand. Wasn't the behavior taking into consideration both overflow and writing-mode? These are both CSS properties.

Sorry for being unclear. When I said "CSS unaware", I meant we hadn't introduced any CSS private property to do autodir, so autodir has nothing to do with CSS's extra assistance. Let me be more specific: autodir does "use" writing-mode and overflow indirectly(without the concept of CSS), in some way, in some condition. But that's not the key point. The key point is: No selectiveness. We cannot selectively turn on autodir for some elements in the document, while turning off autodir for some other elements in the same document. Because we do not have such a CSS property that selectively does it.

Suppose the gallery is vertical instead of horizontal. Why should that be different? Either the user wants to scroll through the image gallery or they don't. Laying out the gallery horizontally vs vertically shouldn't make a difference to whether scroll events are sent to the gallery or the main page.

It does matter based on whether autodir is enabled.

<article class="very-tall"> <!--overflows vertically-->
    ...
    <div style="overflow:auto" class="very-wide"><img ...><img ...>...</div> <!--overflows horizontally-->
    ...
</article>

If autodir is disabled, a user can scroll the <article> from top to down, using plain wheel scroll(plain means no Shift), without the possibility of accidentally falling into the gallery. Because plain wheel scroll will not be changed by disabled autodir, so, the gallery is "essentially an unscrollable element" from the perspective of plain wheel scroll.

If autodir is enabled, then there's possibility of falling into the gallery.

[Zhang-Junzhi]

Let me summarize my personal key solution for this topic in possibly a shortest sentence:

All we need is selectiveness.

Example 1:

<style>
div
{
    overflow: auto;
}
.i-am-pretty-sure-users-will-be-interested
{
    primary-overflow-direction: horzizontal;
}
</style>

<article class="very-tall">
    ...
    <div class="very-wide i-am-not-sure-users-will-be-interested">...</div>
    ...
</article>

<article class="very-tall">
    ...
    <div class="very-wide i-am-pretty-sure-users-will-be-interested">...</div>
    ...
</article>

Example 2:

<!--According to to normal reasoning-->
<html style="writing-mode: vertical-rl; primary-overflow-direction: horizontal;">
    ...
</html>

Example 3:

<!--For some reason, the scroll direction users are more interested in may still be vertical.
For example, this is an old page using "writing-mode" for layout due to historical reasons.
Because it doesn't have use primary-overflow-direction, so we don't break compatibility.-->
<html style="writing-mode: vertical-rl;">
    ...
</html>

[Zhang-Junzhi]

BTW, just one more thing: A name just came to my mind: more-interesting-overflow-direction, which I think reflects the intention of the property better than my previously proposed name primary-overflow-direction.

But more-interesting-overflow-direction is awfully long due to my English proficiency. I believe someone can think of a better name.