- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 15:22:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Setting the primary scrolling direction for a scroll container`, and agreed to the following: * `RESOLVED: A scrolling device with a primary direction should scroll the root scroller in the block flow axis of the principal writing mode` <details><summary>The full IRC log of that discussion</summary> <emeyer> fantasai: There's an issue about vertical-text document means your primary scroll direction is horizontal and that's not hooked to the scroll wheel<br> <emeyer> …So deves are having to capture elements and code around that<br> <emeyer> …The obvious thing to me is if your principal writing mode is horizontal, then if you have a 1D scrolling device it should scroll in that direction<br> <emeyer> …Do others agree? Should we clarify?<br> <flackr> q+<br> <emeyer> astearns: Is the person who raised it asking for a switch?<br> <emeyer> fantasai: Yes, but I think it would be better to change the default and then we can add a switch if one is needed<br> <astearns> ack flackr<br> <iank_> q+<br> <emeyer> flackr: I was going to ask if we know the cases where we have a 1-axis device?<br> <emeyer> …I think it would be bad to change a touchpad where it's easy to scroll both horizontally and vertically<br> <emeyer> …I'm worried that we'll get into cases where we do this on devices where it doesn't make sense to do this<br> <astearns> there are mice with 2d scroll wheels, too<br> <bramus> Plugging in a regular mouse with a scrollwheel on macos has this 1-axis limitation<br> <emeyer> …Alternate idea: if your primary physical axis is not scrollable, we change it to a logical axis<br> <emeyer> fantasai: I think that will work in some cases but not others<br> <emeyer> …I run into sites that scroll both directions, but one direction only a little bit<br> <emeyer> …It would be awkward if when you resize the window, the scroll wheel starts or stops working<br> <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1358017#c0<br> <astearns> ack dbaron<br> <TabAtkins> I think this needs to only apply to 1-d scroll affordances<br> <emeyer> dbaron: If you dig through the comments, there's a link to a Bugzilla issue that this started with a meeting we had with JP publishers in 2017<br> <TabAtkins> q+<br> <emeyer> …They said they were reluctant to publish with vertical text because mouse scroll wheels weren't working as expected<br> <emeyer> …I agree with Rob that we need to be careful about assuming what an implementation knows<br> <emeyer> …The fact that you have vertical scroll events doesn't tell you if a user can handle horiztonal scrolls<br> <emeyer> …We should avoid an implementation that assumes you know that<br> <emeyer> flackr: I wonder if we should fix this in the OS<br> <emeyer> fantasai: At some point the browser has to be involved because the OS doesn<br> <florian> q+<br> <emeyer> s/doesn/doesn't know the scroll direction/<br> <florian> q-<br> <emeyer> flackr: Yeah, if it's a 1D scroll wheel<br> <fantasai> s/scroll direction/writing mode/<br> <astearns> ack iank_<br> <emeyer> iank_: Alison, did Edge have an -ms-scroll property at one point?<br> <emeyer> alisonmaher: Not familiar, can look into it<br> <astearns> ack TabAtkins<br> <emeyer> TabAtkins: This ties into David's points: in terms of events we get, we can tell if something is a scroll wheel, right?<br> <fantasai> s/can/can't/<br> <emeyer> …But if you have a 2D scroll wheel, we can't tell that<br> <emeyer> flackr: I think touchpads get sent at scroll events with distance in each direction<br> <emeyer> …There is a difference between precise and non-precise scrolls and that's usually where the differentiation happens<br> <iank_> https://learn.microsoft.com/en-us/previous-versions/hh973361(v=vs.85)<br> <emeyer> TabAtkins: This does annoy me; if there's a reasonable expectation in the common scroll wheel case, even if we can't quite tell when a wheel is 2D, we should spend config space on this as we do for asking users which way they want their 1D wheels to move<br> <kizu> q+<br> <astearns> ack kizu<br> <emeyer> …With vertical text, if we get imprecise events, we should stick with block direction<br> <emeyer> kizu: I can imagine a case where we reach the default axis, we want to switch<br> <emeyer> q+<br> <emeyer> …With a switch property, you could switch directions<br> <emeyer> …mid-page<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to reply<br> <emeyer> fantasai: I don't think that would make sense<br> <emeyer> …Say you load a page with an image slightly too wide, do you expect to scroll over in the image and then scroll down in the whitespace after that?<br> <emeyer> kizu: [missed[<br> <kbabbitt> re: -ms-scroll-* events mentioned by iank_ - those were related to scroll snap points / touch overscroll features<br> <emeyer> fantasai: We know the main axis, but we might not know whether we have a scroll wheel that works in two different axes<br> <bramus> Sidenote: You can (ab)use scroll-driven animations for the behavior kizu wants: https://scroll-driven-animations.style/demos/horizontal-section/css/<br> <emeyer> …If you have a 2D wheel, use it, but if you have a 1D wheel, then that's the one that should go in the main direction of the document<br> <flackr> q+<br> <astearns> ack emeyer<br> <iank_> kbabbitt: what about the "-ms-scroll-translation" property?<br> <fantasai> emeyer: Literally today, I visited this page<br> <emeyer> https://www.propublica.org/article/microsoft-solarwinds-golden-saml-data-breach-russian-hackers<br> <khush> q+<br> <fantasai> emeyer: you get partly down the page and then there's a horizontal bit that scrolls<br> <TabAtkins> kbabbitt, I think we should standardize that *as well*, separately from this conversation.<br> <fantasai> emeyer: this is exactly this use case, scrolling down the main axis<br> <fantasai> emeyer: and it switched directions<br> <fantasai> emeyer: I had no problem understanding what was happening<br> <fantasai> emeyer: This is a thing that's done, would be nice ot address via CSS rather than using JS<br> <TabAtkins> that way `scroll-translation` can be used by a page *on purpose* to do the thing Eric is talking about<br> <bramus> https://scroll-driven-animations.style/demos/horizontal-section/css/<br> <fantasai> bramus: do that with scroll-driven animations<br> <florian> q+<br> <kbabbitt> iank_, oh I missed that one - would need to dig into it<br> <fantasai> bramus: it's a hack...<br> <astearns> ack flackr<br> <emeyer> flackr: Scrolling the primary axis and then the secondary axis does not give you access to everything<br> <florian> q-<br> <emeyer> …This isn't a universal solution<br> <emeyer> …We do offer a shift key modifier<br> <emeyer> …We could look at the writing mode of a scroller to change direction for subscrollers, but I'm not a fan of the mode-switching<br> <TabAtkins> q+<br> <astearns> ack khush<br> <bramus> +1<br> <bramus> q+<br> <emeyer> khush: Was going to ask if there's any reason this would be l;imited to the root scroller instead of it changing when you're focused on a subscroller<br> <emeyer> …Using writing mode seems an intuitive solution, but examples show you might want to switch based on writing mode<br> <emeyer> s/based on/based on things other than/<br> <fserb> welcome back :)<br> <emeyer> fantasai: That's what I would want, but can't find where I did<br> <emeyer> …I started with the writing mode of the principal document, since that seemed to make sense<br> <astearns> ack TabAtkins<br> <fserb> pasting the pre-split comments:<br> <fserb> fantasai: I can't find where I wrote the thing that the viewport should be based on principal writing mode of document, and the scroller should be based on the writing mode of the scroller<br> <fserb> …If you can only scroll in one axis, then you attach to the scrollable axis<br> <fserb> done.<br> <fantasai> s/in one axis/in one axis due to overflow-x vs overflow-y /<br> <emeyer> TabAtkins: Kevin mentioned some ms- prefixed things about scroll wheel events turn into vertical or horizontal scroll<br> <emeyer> …We could scope the automatic one to the root document based on the writing mode<br> <TabAtkins> -ms-scroll-translation<br> <emeyer> iank_: It would be interesting to know how -ms-scroll-translation actually behaved<br> <florian> q+<br> <fantasai> /me q?<br> <astearns> ack bramus<br> <emeyer> kbabbitt: Will need to research<br> <fantasai> s| /me q?||<br> <emeyer> bramus: I liked what Elika suggested to attach to the scrollable axis<br> <florian> q-<br> <emeyer> …Seems like a good idea<br> <iank_> kbabbitt: specifically would be curious what got plumbed through from the OS to handle that case.<br> <flackr> q+<br> <bramus> s/to attach to the/to eventually attach to the<br> <emeyer> astearns: Are we arriving at yes, we want to see if we can detect scrolling and attach to the main document?<br> <TabAtkins> (sorry, scribe is not on a mic so i couldn't hear him asking for an interrupt)<br> <emeyer> dholbert: What if you have two mice and one is 1D and one is 2D?<br> <emeyer> …And both are connected, and both are giving scroll events?<br> <emeyer> TabAtkins: I don't think we can tell that even if you're only using one mouse at a time, so we'd have to treat as: the 2D mouse scrolled vertically would give you horizontally<br> <emeyer> flackr: This is going to me common because every laptop user has a touchpad and many have a mouse attached<br> <florian> q+<br> <astearns> ack flackr<br> <emeyer> TabAtkins: If you're doing something physical, it's terrible to make that change direction<br> <astearns> ack florian<br> <emeyer> flackr: Responding to Elika's 1D scroll suggestion, there's a risk of scrolling down a long vertical page, landing on a horizontal scroll without knowing, and preventing further vertical scroll<br> <bramus> Good remark.<br> <emeyer> florian: Didn't catch this was concluded, but if we are facing horizontal scroller, presumably it's not really flipping, you scroll as possible<br> <khush> q+<br> <emeyer> …What I mean is, the H scrolwheel of a mouse should always get you H scrolling even if you remap it<br> <astearns> ack khush<br> <emeyer> khush: Rob has a good point that if you try to do this automatically, you can start mapping scroll behavior by mistake<br> <emeyer> …IN the ProPublica case linked, the author does want you to do that, and it's why a switch might be a good thing here<br> <TabAtkins> That's why I was suggesting the default only apply to the root scroller, fwiw<br> <emeyer> …Letting the author having a say in that is good<br> <emeyer> flackr: I think flipping a 1D is uncontentious<br> <astearns> ack dbaron<br> <emeyer> astearns: For more, we probably need a proeprty<br> <emeyer> dbaron: Worried we're getting too far into specifying UI instead of web tech<br> <emeyer> …Or at least, speccing how UAs handle particular input devices<br> <emeyer> …I'm not sure how much of this discussion is specificable<br> <emeyer> TabAtkins: We have a lot of stuff about how to handle scrolling on a page, like scroll snapping<br> <emeyer> …I feel like this is in the same wheelhouse<br> <emeyer> dbaron: I think distinguishing between precise and wheel scroll might be an interesting idea but I don't think it can go in CSS<br> <emeyer> fantasai: I think it would need to be more abstract<br> <astearns> ack fantasai<br> <emeyer> TabAtkins: Agreed, though with a note describing how to tell devices apart<br> <flackr> +1<br> <emeyer> fantasai: +1 to Tab in IRC, it's why I raised this in the first place<br> <emeyer> …With small blocks, there is a concern<br> <emeyer> …If the author put a vertical carousel in there, it would be a problem to deal with<br> <emeyer> …We should explore, but we'll need to add advice to scroll in the document's primary direction<br> <emeyer> …As to a separate property, if we can avoid making people use it most of the time, that would be better<br> <emeyer> …Hopefully it wouldn't be necessary most of the time<br> <emeyer> astearns: Can you summarize a resolution just for the primary writing direction?<br> <flackr> suggestion? The UA should map known 1D scroll events to the document's writing mode block direction<br> <fantasai> PROPOSED: A scrolling device with a primary direction should scrol the root scroller in the block flow axis of the principal writing mod.<br> <fantasai> s/mod/mode/<br> <fantasai> s/scrol/scroll/<br> <emeyer> astearns: Any objections?<br> <fantasai> s/primary direction/primary axis/<br> <emeyer> khush: Should we add the clarification about precise and imprecise scroll?<br> <emeyer> flackr: No<br> <emeyer> fantasai: No, that needs to be left up to implementation<br> <flackr> having a "primary direction" is intentionally vague about how you tell that<br> <emeyer> …We can give direction, but need to leave it up to UAs<br> <emeyer> RESOLVED: A scrolling device with a primary direction should scroll the root scroller in the block flow axis of the principal writing mode<br> <dbaron> bramus: non-root scrollers still an open issue?<br> <dbaron> ?: yes<br> <bramus> s/?: yes/fantasai and astearns: yes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10060#issuecomment-2165994109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 15:22:34 UTC