[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.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-5] Disabled scroll-button state and styling, and agreed to the following:

• RESOLVED: Accept flackr's proposal in the issue.

The full IRC log of that discussion

<TabAtkins> flackr: I don't expect this to be too controversial
<TabAtkins> flackr: the scroll buttons behavior is to scroll in a direction
<TabAtkins> flackr: it seems reasoanble that if the scroller can't scroll any more in that direction, the button should be disabled
<fantasai> +1 to the proposal
<TabAtkins> flackr: consistent with ARIA recs for prev/first buttons in a carousel. Not inert, disabled; my udnerstanding is AT treats them differently.
<TabAtkins> flackr: and they should apply a disabled style; the UA style will match the button disabled style
<TabAtkins> q+
<TabAtkins> argyleink: agree this is user expectation. not making it inert is good so it doesn't just disappear.
<TabAtkins> argyle: [rereads his own comment]
<TabAtkins> argyle: ah, this was in competition with the "cyclical scrolling"
<TabAtkins> argyle: if you're in netflix or something, they don't stop you, they cycle back to the other side
<TabAtkins> argyle: either flipping back, or virtualizing to make it infinite scroll
<TabAtkins> argyle: it's nice, but we should follow aria behavior here
<TabAtkins> argyle: devs can build another behavior if they want it
<TabAtkins> argyle: other concern is, the buttons are siblings, so i thought they couldn't tap into the scroll-state query
<TabAtkins> argyle: but they can, per Rune
<TabAtkins> argyle: so that's a healthy default.
<astearns> s/Rune/Rene/
<TabAtkins> flackr: I'm fully supportive of enablign cyclical scrolls, but I think we need to extend the Overflow model for that
<TabAtkins> argyle: agree
<fantasai> +1 flackr, exactly why I was on the queue
<vmpstr> +1
<TabAtkins> argyle: maybe if that value was present these buttons didn't disable
<TabAtkins> flackr: yes, they'd change behavior because there is no end
<fantasai> scribe+
<fantasai> TabAtkins: How do you select them when they're in the disabled state?
<fantasai> flackr: :disabled
<fantasai> TabAtkins: cool
<astearns> ack TabAtkins
<astearns> ack fantasai
<TabAtkins> fantasai: strong +1 to everything rob just said about hwo looping scroll should work
<fantasai> s/hwo/how
<TabAtkins> argyle: in the UA, is there a scroll-state query, or is this a magic pseudo-state instead?
<TabAtkins> argyle: so if i didn't want it disabled on the edges, how do i opt out?
<TabAtkins> flackr: you could remove the disabled styling using :disabled
<TabAtkins> flackr: but they'd still be disabled buttons. unsure what you'd expect them to do. in the future we could target them with event listeners and add custom handling
<TabAtkins> flackr: but right now you can't listen for events on the buttons
<TabAtkins> argyle: gotcha, so for this version, the scroller buttons will automatically disable at the edges. you can style differently, but they're still disabled. until later when we have other overflow behaviors.
<TabAtkins> flackr: or until we start selecting in JS the pseudo-elements, or some other way of listening to events on pseudos
<TabAtkins> [some discussion about getComputedStyle()'s pseudo argument)
<TabAtkins> astearns: I think you can put a listener on the host and check where the click was...?
<TabAtkins> flackr: you can't actually tell the click was on the pseudo unless you determine from the position
<TabAtkins> argyle: same as ::backdrop, yeah
<TabAtkins> dbaron: I was discussing this with Mason a few days ago
<TabAtkins> flackr: yeah we should fix it
<TabAtkins> dbaron: Mason ran into this exact problem last week
<TabAtkins> flackr: so in a future we fix this you could hook into the buttons and do something else
<TabAtkins> argyle: [re-summarizes]
<TabAtkins> argyle: and it's styled as a button, but with text contents... i guess that's a different issue
<TabAtkins> argyle: sounds good overall, good defaults
<TabAtkins> astearns: so desired resolution?
<TabAtkins> flackr: apply the disabled behavior and style when you can't scroll further in the associated direction
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Accept flackr's proposal in the issue.
<dbaron> (I think the discussion I mentioned with Mason was about https://github.com/whatwg/html/pull/10737 which actually (I think) ended up putting the click rect check in the spec PR!)