W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

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

From: David Bokan via GitHub <sysbot+gh@w3.org>
Date: Tue, 08 Oct 2019 07:10:26 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-539374775-1570518625-sysbot+gh@w3.org>
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. 

-- 
GitHub Notification of comment by bokand
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4380#issuecomment-539374775 using your GitHub account
Received on Tuesday, 8 October 2019 07:10:27 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:54 UTC