[css-overflow-5] Disabled scroll-button state and styling

[flackr]

When the scroll container is at the limit of scrolling in the given direction, the ::scroll-button pseudo-elements for those directions should be treated as disabled. They should also be stylable in some way allowing developers to indicate this state.

Presumably this would be styled by:

::scroll-button(<direction>):disabled {
  opacity: 0.6;
}

[argyleink]

i'd attempted this using scroll-state(overflowing)

::scroll-next-button {
  @container not scroll-state(overflowing: right) {
    interactivity: inert;
    opacity: 0.5;
  }
}

but since the buttons are siblings to the overflow area and not children, I don't currently have the hook.

i'm of the opinion that the UA shouldnt do this, that developers can opt-out using CSS like the above, to change the behavior. it's easier to remove the cyclical and never disabled state, then to try and re-enable these interaction patterns.

[vmpstr]

it's easier to remove the cyclical and never disabled state, then to try and re-enable these interaction patterns.

My concern with by-default being cyclical is that scrolling will still not be cyclical, which seems like a bad inconsistency

[flackr]

i'd attempted this using scroll-state(overflowing)

::scroll-next-button {
  @container not scroll-state(overflowing: right) {
    interactivity: inert;
    opacity: 0.5;
  }
}

but since the buttons are siblings to the overflow area and not children, I don't currently have the hook.

My understanding is that disabled is still present in accessibility, whereas inert is completely removed, and so it is important to represent the button in a disabled state.

i'm of the opinion that the UA shouldnt do this, that developers can opt-out using CSS like the above, to change the behavior. it's easier to remove the cyclical and never disabled state, then to try and re-enable these interaction patterns.

I think making the scroll button cycle back to the start feels too magical to do automatically, and often unexpected for a scroll button. We could later add a parameter to the function syntax maybe? Or alternately if/when we tackle cyclic scrolling we could consider a different model where instead of smoothly scrolling forward to the beginning it scrolls back.