scroll-policy: ease horizontal scrolling by wheel in vertical writing mode

[Zhang-Junzhi]

I propose to introduce a new property scroll-policy, in order to ease horizontal scrolling in vertical writing mode:

The property has two values: none (default value), auto.

none keeps the traditional scroll policy unchanged, in order to avoid breaking upward compatibility.

auto tells the browsers to take full advantage of scrolling operations, as much as they like, without fearing any compatibility:

For example, if an element is in vertical-rl mode, and overflows in only the horizontal direction, then the browser can quite confidently set the default action of the upward wheel event as rightward scrolling, and the default action of the downward wheel event as leftward scrolling.

This feature is significantly helpful if the whole page is more than one screen in vertical writing mode, and will make the vertical writing pages eventually become practical in real-world.

[Zhang-Junzhi]

FYI, Firefox 61 introduced a similar feature called Autodirectional Scroll Wheel (autodir in short), You can turn it on in about:config to experience it, so it just needs standardization.

[bokand]

Blink implementer here: I'm sympathetic to the use case - I think it'd be helpful and something we should get to work well. However, I do have some specific points and questions below.

The proposal above seems a bit too ambiguous to me - it's not really specific as to what the user agent must do or what it can do. Is there a reason why we don't just make the property more explicit? e.g.

scroll-policy : auto(default) | writing-mode

auto: Current behavior
writing-mode: Determine primary scroll axis based on writing mode

i.e. A page can opt-in to the behavior if scroll-policy is set to writing-mode so that the wheel's primary scroll axis is determined based on the writing-mode/direction of the scroller. A UA could implement a "flag/setting" to let users control this by specifying scroll-policy: writing-mode in the UA stylesheet.

Question: what happens to the values in the wheel event? Do the deltaX|Y get flipped or do we continue to report the delta in deltaY regardless of writing-mode? To further complicate this, when a wheel event is first dispatched, it doesn't know which element will handle the scroll so if the scroll axis comes from an individual element's writing-mode, we can't correctly set the value in deltaX|Y. I suspect it might be most rational to leave the deltaX|Y unchanged from today (though we'd need to amend existing specs).

Is supporting multiple writing modes in sub-scrollers a common/important use case or could we just look at and use the documentElement's writing mode?

if an element is in vertical-rl mode, and overflows in only the horizontal direction,

I'm unconvinced this should depend on the state of overflow. I think this could be somewhat unintuitive in some edge-cases. Unless I'm missing something, I think it'd be more rational from a platform point of view to have the behavior be more explicitly declared and not depend on content specifics. e.g. resizing the browser window shouldn't change the scroll direction of the mouse wheel IMHO.

Sorry if some of this is rehashing old issues. I started looking through the history in https://bugzilla.mozilla.org/show_bug.cgi?id=1358017 but it's extremely long so I'd appreciate if you could summarize/answer some of these details and what the experience has been like with Firefox's approach so far, specifically issues that came up and motivate your current design/thinking.

FWIW, I think everything I bring up above can be resolved so thinking through some of these cases we could come to some reasonable interoperable behavior.

[bokand]

By the way, there's a related bug in Blink tracking solving this issue.

[Zhang-Junzhi]

Is there a reason why we don't just make the property more explicit? e.g.

scroll-policy : auto(default) | writing-mode

auto: Current behavior
writing-mode: Determine primary scroll axis based on writing mode

I have no issue replacing the keyword auto with writing-mode instead, but I prefer auto. one reason I used auto is because the keyword has already been used in the CSS, the other reason is that it just tells browsers to maximise easing the content scrolling, no matter in what way they like, everything is not specific(browser-dependent), even though CSS spec can specifically suggest browser to make vertical wheel scroll's default action as content's horizontal scrolling when vertical writing content only overflows in horizontal direction.

Question: what happens to the values in the wheel event? Do the deltaX|Y get flipped or do we continue to report the delta in deltaY regardless of writing-mode?

Delta values won't be changed, only the default behaviour of the wheel event will be changed.

I think it makes sense to not change delta, all raw input from the user should be respected, so that script programmers are still able to receive intact input info from wheel. Remember that according to the HTML spec, a wheel event doesn't event necessarily lead to scroll event, the default action is implementation-defined, even though almost all browsers do the same(setting the default action of wheel scroll as content scroll).

Is supporting multiple writing modes in sub-scrollers a common/important use case or could we just look at and use the documentElement's writing mode?

I would like to suggest the property be an inheritable property(as writing-mode is), and the effect is based on the current element, not based on the root element. Using multiple writing modes is not very necessary in most cases, let alone erratic multiple writing modes, If erratic multiple writing modes are applied on an page, then the the developer can simply avoid using scroll-policy(letting it be none), so it doesn't do any harm.

if an element is in vertical-rl mode, and overflows in only the horizontal direction,

I'm unconvinced this should depend on the state of overflow. I think this could be somewhat unintuitive in some edge-cases.

The developer can avoid using the auto scroll-policy, until the developer is quite convinced of the stability of the state of overflow, for example, in the case that one directional scroll bar is quite more likely than the other one to appear.

If the developer uses the writing-mode property in the correct way(I.E. really for writing mode), then it's perfect. If the developer uses the writing-mode property in the wrong way(E.G. for layout), then it may be some erratic cases(some old code may make layout in this wrong way), so that's why this property is proposed, we do not make an one-size-fits-all approach, we should let the scroll-policy default to none, in order to keep the compatibility of the existing WEB world, but we also need to ease horizontal scrolling of further pages in vertical writing mode.

[Zhang-Junzhi]

Sorry if some of this is rehashing old issues. I started looking through the history in https://bugzilla.mozilla.org/show_bug.cgi?id=1358017 but it's extremely long so I'd appreciate if you could summarize/answer some of these details and what the experience has been like with Firefox's approach so far,

In short, Firefox AutoDir works this way:

If it's turned on, then if the current pointed element is only scrollable(only overflows) in one direction, then let the vertical wheel event just make the content scroll in that direction, no matter it's horizontal or vertical.
(Firefox AutoDir can only either be turned on, or turned off, so it's not CSS-controllable, so it's not perfect, turning on it may break the current web behaviour, so it's disabled by default, the experience feedback received from users is limited. But if we implement it via scroll-policy with a non-default value, it may not be an issue).

specifically issues that came up and motivate your current design/thinking.

Whole-page-in-vertical-writing-mode is the motivation, this is the traditional writing style in CJK. But currently in the WEB world, developers are hesitant to use it, I think the one primary reason is because it's not practical - to be specific - because of unease of horizontal scroll on desktop computers with only one directional mouse wheel(Small touchable screens like mobile phones don't have such issue). CSS has been doing great efforts in writing modes and logicalising layout properties, etc., but unfortunately, yet still leaving the practical issue like horizontal scrolling unresolved.

[bokand]

CSS Property

I have no issue replacing the keyword auto with writing-mode instead, but I prefer auto. one reason I used auto is because the keyword has already been used in the CSS

I'm not a CSS expert but I believe that auto is conventionally used for the default or initial value of a property. It might be surprising that it's not the default. It also isn't very indicative of what the value does which is unhelpful to the author.

the other reason is that it just tells browsers to maximise easing the content scrolling, no matter in what way they like

I think that absent good reasons (e.g. allowing UA flexibility for performance reasons), it's better to specify behavior as specifically as possible. This ensures maximum interoperability. In other words, if we allow UAs to implement this feature in "no matter in what way they like" then multiple conforming browsers might behave differently. This makes life difficult for web authors. We should specify exactly how and what should happen for each value.

UI Event details

I think it makes sense to not change delta, all raw input from the user should be respected, so that script programmers are still able to receive intact input info from wheel. Remember that according to the HTML spec, a wheel event doesn't event necessarily lead to scroll event, the default action is implementation-defined.

While true, the current spec text of wheelEvent.deltaY is:

In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the y-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled.

I think it'd be a stretch to say that a horizontal scroll doesn't count as a scroll. My initial thought is that I agree not changing the wheel event deltas is probably the right thing to do but we'd at least need to amend this spec.

One related-note here is the proposal for percentage-based scrolling in Chromium. It runs into the same issue in this spec.

Per-Element of Per-Document

I would like to suggest the property be an inheritable property(as writing-mode is), and the effect is based on the current element, not based on the root element

I think if we don't have to change the wheel event deltas then this is probably fine

Overflow issues

The developer can avoid using the auto scroll-policy, until the developer is quite convinced of the stability of the state of overflow, for example, in the case that one directional scroll bar is quite more likely than the other one to appear.

I'm worried that the state of overflow can differ depending on devices and the environment so it makes it difficult for developers to be certain. Layout is difficult...

If the developer uses the writing-mode property in the correct way(I.E. really for writing mode), then it's perfect. If the developer uses the writing-mode property in the wrong way(E.G. for layout), then it may be some erratic cases

I'm not familiar with writing-mode best-practices. Could you help me understand what you mean by this? How is writing-mode used incorrectly and what erratic cases does this lead to?

we should let the scroll-policy default to none, in order to keep the compatibility of the existing WEB world, but we also need to ease horizontal scrolling of further pages in vertical writing mode.

I agree the default should be the existing behavior to preserve compatibility. However, if the author must explicitly opt-in to this behavior, indicating that the page is meant to be read in a horizontal manner, is there any reason we can't always cause horizontal scrolling in this case, regardless of overflow? It seems to me this would be more predictable and more straightforward.

[Zhang-Junzhi]

I'm not familiar with writing-mode best-practices. Could you help me understand what you mean by this? How is writing-mode used incorrectly and what erratic cases does this lead to?

For example, the following code uses writing-mode incorrectly, it's used to achieve top-to-bottom-and-then-left-to-right layout, not for actual vertical writing text:

<div style="writing-mode: vertical-lr;">
	<div style="display: inline-block; writing-mode: horizontal-tb;">div 1</div>
	<div style="display: inline-block; writing-mode: horizontal-tb;">div 2</div>
	<div style="display: inline-block; writing-mode: horizontal-tb;">div 3</div>
</div>

is there any reason we can't always cause horizontal scrolling in this case, regardless of overflow? It seems to me this would be more predictable and more straightforward.
I'm worried that the state of overflow can differ depending on devices and the environment so it makes it difficult for developers to be certain. Layout is difficult...

I have exactly the same concern as you.

I had previously issued another proposal before issuing this proposal. Because the previous proposal seems over complicated to begin with(it's hard to be patient enough for readers to get through at once), so I decided to close it and then started this simplified version.

In the previous proposal, the property has five values, where none and both are the same as none and auto in this proposal. And the horizontal value is exactly what you want here.

[Zhang-Junzhi]

the other reason is that it just tells browsers to maximise easing the content scrolling, no matter in what way they like

I think that absent good reasons (e.g. allowing UA flexibility for performance reasons), it's better to specify behavior as specifically as possible. This ensures maximum interoperability. In other words, if we allow UAs to implement this feature in "no matter in what way they like" then multiple conforming browsers might behave differently. This makes life difficult for web authors. We should specify exactly how and what should happen for each value.

I think scroll-policy can only suggest it, in order to be technically correct, because wheel scroll even doesn't necessarily trigger content scroll according to the spec, the default action of wheel scroll is undefined according to the spec. Even almost all browsers default wheel scroll's action to content scroll, I still think scroll-policy can only suggest how to behave for any browsers that already use wheel scroll as content scroll, nothing is mandatory.

Fortunately, although it's technically correct for the CSS to just suggest how to behave, I believe in the real world, almost all browsers will implement the property in the same way.

From the view of developers, that means developers only need to know that scroll-policy: auto will prioritise easing scroll in the major direction(or scroll-policy: horizontal will prioritise easing scroll horizontally, if any in the further), but the developer doesn't need to worry about those specific means, which specific means the browsers will take is transparent to the developer.

[Zhang-Junzhi]

Comparing to scroll-policy, is prioritised-scroll-direction(or such like) a more understandable property name? (A bit lengthy name, but I am not a native speaker).

And there can be four values:
none,
auto(depending on state of overflow),
horizontal(always horizontal first),
vertical(always vertical first)

[bokand]

Comparing to scroll-policy, is prioritised-scroll-direction(or such like) a more understandable property name? (A bit lengthy name, but I am not a native speaker).

I think that's better, prioritized-scroll-direction makes the function of the property more clear just from reading it. I'd clarify it even more to primary-scroll-axis.

I think scroll-policy can only suggest it, in order to be technically correct, because wheel scroll even doesn't necessarily trigger content scroll according to the spec, the default action of wheel scroll is undefined according to the spec. Even almost all browsers default wheel scroll's action to content scroll, I still think scroll-policy can only suggest how to behave for any browsers that already use wheel scroll as content scroll, nothing is mandatory.

Yes, but we can mandate specifically what happens in the case that the UA's default action is scrolling. That's the case with the wheelEvent.deltaY definition, for example. Example spec text:

The primary-scroll-axis property determines which axis must be scrolled when non-directional scrolling inputs are used (e.g. single-axis mouse wheel). If the default action of a UA an event is to scroll, and the event is non-directional, the UA must apply any scrolling to the primary scroll axis. If the default action of the UA is not scrolling, this property has no effect.

Values might be defined something like this:

auto: (default) The user agent may determine the primary scroll axis // i.e. existing behavior, browsers just use vertical
writing-mode: The primary scroll axis is determined from the writing mode, based on the block flow axis.

These are just examples of how I'd write this, not necessarily detailed enough. Also, I suppose you could write auto to mean "vertical" but auto in CSS typically means "let the UA decide" which usually means "do what we've always done", in this case: "vertical".

[a2sheppy]

Point of order: would it be prioritised-scroll-direction or prioritized-scroll-direction? I believe it should be the latter, since most existing stuff in the web specs use American-style spellings, such as XMLSerializer and all the places involving color.

[Zhang-Junzhi]

Point of order: would it be prioritised-scroll-direction or prioritized-scroll-direction? I believe it should be the latter, since most existing stuff in the web specs use American-style spellings, such as XMLSerializer and all the places involving color.

That makes senses. I am personally used to the British-style, but it doesn't matter, since either one is okay to me.

I think the name primary-scroll-axis (suggested by @bokand) could be a better one.