- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Nov 2024 16:43:55 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: I don't expect this to be too controversial<br> <TabAtkins> flackr: the scroll buttons behavior is to scroll in a direction<br> <TabAtkins> flackr: it seems reasoanble that if the scroller can't scroll any more in that direction, the button should be disabled<br> <fantasai> +1 to the proposal<br> <TabAtkins> flackr: consistent with ARIA recs for prev/first buttons in a carousel. Not inert, disabled; my udnerstanding is AT treats them differently.<br> <TabAtkins> flackr: and they should apply a disabled style; the UA style will match the button disabled style<br> <TabAtkins> q+<br> <TabAtkins> argyleink: agree this is user expectation. not making it inert is good so it doesn't just disappear.<br> <TabAtkins> argyle: [rereads his own comment]<br> <TabAtkins> argyle: ah, this was in competition with the "cyclical scrolling"<br> <TabAtkins> argyle: if you're in netflix or something, they don't stop you, they cycle back to the other side<br> <TabAtkins> argyle: either flipping back, or virtualizing to make it infinite scroll<br> <TabAtkins> argyle: it's nice, but we should follow aria behavior here<br> <TabAtkins> argyle: devs can build another behavior if they want it<br> <TabAtkins> argyle: other concern is, the buttons are siblings, so i thought they couldn't tap into the scroll-state query<br> <TabAtkins> argyle: but they can, per Rune<br> <TabAtkins> argyle: so that's a healthy default.<br> <astearns> s/Rune/Rene/<br> <TabAtkins> flackr: I'm fully supportive of enablign cyclical scrolls, but I think we need to extend the Overflow model for that<br> <TabAtkins> argyle: agree<br> <fantasai> +1 flackr, exactly why I was on the queue<br> <vmpstr> +1<br> <TabAtkins> argyle: maybe if that value was present these buttons didn't disable<br> <TabAtkins> flackr: yes, they'd change behavior because there is no end<br> <fantasai> scribe+<br> <fantasai> TabAtkins: How do you select them when they're in the disabled state?<br> <fantasai> flackr: :disabled<br> <fantasai> TabAtkins: cool<br> <astearns> ack TabAtkins<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: strong +1 to everything rob just said about hwo looping scroll should work<br> <fantasai> s/hwo/how<br> <TabAtkins> argyle: in the UA, is there a scroll-state query, or is this a magic pseudo-state instead?<br> <TabAtkins> argyle: so if i didn't want it disabled on the edges, how do i opt out?<br> <TabAtkins> flackr: you could remove the disabled styling using :disabled<br> <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<br> <TabAtkins> flackr: but right now you can't listen for events on the buttons<br> <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.<br> <TabAtkins> flackr: or until we start selecting in JS the pseudo-elements, or some other way of listening to events on pseudos<br> <TabAtkins> [some discussion about getComputedStyle()'s pseudo argument)<br> <TabAtkins> astearns: I think you can put a listener on the host and check where the click was...?<br> <TabAtkins> flackr: you can't actually tell the click was on the pseudo unless you determine from the position<br> <TabAtkins> argyle: same as ::backdrop, yeah<br> <TabAtkins> dbaron: I was discussing this with Mason a few days ago<br> <TabAtkins> flackr: yeah we should fix it<br> <TabAtkins> dbaron: Mason ran into this exact problem last week<br> <TabAtkins> flackr: so in a future we fix this you could hook into the buttons and do something else<br> <TabAtkins> argyle: [re-summarizes]<br> <TabAtkins> argyle: and it's styled as a button, but with text contents... i guess that's a different issue<br> <TabAtkins> argyle: sounds good overall, good defaults<br> <TabAtkins> astearns: so desired resolution?<br> <TabAtkins> flackr: apply the disabled behavior and style when you can't scroll further in the associated direction<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: Accept flackr's proposal in the issue.<br> <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!)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11216#issuecomment-2489083729 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 November 2024 16:43:56 UTC