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

#### 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](!topic/blink-dev/U3kH6_98BuY) 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.

GitHub Notification of comment by bokand
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 9 October 2019 07:17:50 UTC