Re: [csswg-drafts] [css-overflow] Remove `prev` and `next` scroll-button-direction (#11249)

> so having _six_ buttons - block-axis, inline-axis, and longest-axis? That could work.

Yes exactly. Though i don't want to overly bias towards ease of implementation. If it's feasible to have the selector change what it matches triggering a restyle / relayout just as we require with many of the other scroll state dependent things, then we should consider what the ergonomics / performance is like and what we'd be losing / gaining to have prev/next be a longest-axis.

My rough thinking, considering the two options:
1. Having prev / next map to block-start / block-end or inline-start / inline-end.
   - Allows authors to style the buttons generically, with axis-specific parts coming from a style block for the axis, e.g.
     ```css
     /* Common button styling */
     .scroller::scroll-button(*) {
       /* Hides all of the buttons so that only the longest axis ones are shown. */
       display: none;
     }

     /* Physical direction specific styling: */
     .scroller::scroll-button(left) { content: url(arrow-left.png); content: "" / "Scroll left"; }
     .scroller::scroll-button(right) { content: url(arrow-right.png); content: "" / "Scroll right"; }
     .scroller::scroll-button(up) { content: url(arrow-up.png); content: "" / "Scroll up"; }
     .scroller::scroll-button(down) { content: url(arrow-down.png); content: "" / "Scroll down"; }

     /* Displays the buttons for the longest direction. */
     .scroller::scroll-button(prev), .scroller::scroll-button(next) {
       display: block;
     }
     ```
   - Layout dependences means that it would probably be a common case of needing an additional style/layout pass.
2. Having prev / next map to a different pair of scroll buttons for longest-axis.
   - Supports transitions on buttons properties if/when the longest axis changes.
   - Makes the selector independent of the layout - layout information is only required at the point of using the button.
   - We might need a mechanism for querying / using the logical and/or physical direction, which could lose much of the benefit gained of having the selector be layout independent.

With both,
- Things like whether they are enabled could require a repeat of the style/layout loop.

My general thinking is that there are real developer benefits to having prev / next map to the direction-specific buttons for use cases where they would be used and that we should try to do this if possible.

-- 
GitHub Notification of comment by flackr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11249#issuecomment-2498761441 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 25 November 2024 18:34:49 UTC