[css-overflow] Remove `prev` and `next` scroll-button-direction

[danielsakhapov]

prev and next <scroll-button-direction> values make ::scroll-button() selectors layout dependent, but the spec doesn't define the time and the way browsers should match it.

I want to discuss if we really need them at all, and then either remove them or better specify what and when to do. This layout dependency for CSS selectors is a new thing, so, I want to also discuss the complexity vs the usefullness of it.

cc: @tabatkins @flackr @lilles

[flackr]

I think one way we could get rid of the layout dependency is to have prev and next be separate from the other scroll-button pseudo-elements. Then the selector always refers to the "prev" and "next" pseudo, whose direction only needs to be known when the button is activated.

That said, I think we could make these work in a similar way to scroll state queries where we rerun style and layout if the matched pseudo changes from the initially matched one.

[tabatkins]

Hm, so having six buttons - block-axis, inline-axis, and longest-axis? That could work.

[flackr]

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.

     /* 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 (could add positioning styles as well here e.g. anchor constraints): */
     .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 button properties if/when the longest axis changes. Though it's unclear how you'd position them to where you want them for the longest axis without knowing that axis at style time.
   • 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.