- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Jul 2021 21:29:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `position:sticky horizontal scrollbar`, and agreed to the following: * `RESOLVED: no change, happy to have discussion continue in-thread or elsewhere` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: position:sticky horizontal scrollbar<br> <TabAtkins> florian: Suggested slution is probably wrong, but use-case is interesting<br> <TabAtkins> florian: Say in middle of a scrollable document, you have a large scrollable element (larger than screen)<br> <TabAtkins> florian: The scrollbar for the element might be off-screen<br> <TabAtkins> florian: So you can't scroll it or even notice it's scrollable maybe<br> <TabAtkins> florian: Suggestion is to make the scrollbar sticky somehow, so it sticks to the edge of the screen<br> <smfr> q+<br> <TabAtkins> florian: If a UA wanted to have an overlay scrollbar that did this, I dont' think we ban this currently, so maybe it's just a QoI<br> <TabAtkins> florian: But we haven't seen any UA attepmts in that direction. So if we're not solving this, how are we letting authors solve it themselves?<br> <TabAtkins> florian: Don't have an answer yet<br> <TabAtkins> smfr: we talked about this a few days ago, any new info?<br> <TabAtkins> florian: 8 days ago the clock ran out<br> <TabAtkins> florian: Roughly, do we expect this'll be solved by UAs? Will we give tools to authors? Or not address it?<br> <TabAtkins> smfr: I think I said this woudl be hard to be QoI, because woudl be hard for UAs to know when they're sticky<br> <TabAtkins> smfr: But since they don't have boxes, authors couldn't directly style scrollbars either<br> <TabAtkins> smfr: would have to invent new primitives<br> <TabAtkins> dbaron[m]: Other hard thing is the bounds of the sticky area<br> <TabAtkins> dbaron[m]: probably don't want the sticky scrollbar right next to the other scrollbar - don't want it right next to the other scrollbar<br> <Rossen_> ack smfr<br> <TabAtkins> dbaron[m]: positioning seems context-dependent<br> <TabAtkins> florian: Should we state that we're open to specific suggestions?<br> <TabAtkins> florian: And since scrollbars aren't boxes, I presume not a selector, but rather a property to make them do the right magic?<br> <TabAtkins> smfr: off-the-cuff suggestion last time was a proxy scrollbar you could just make and tie it to scrolling a box<br> <TabAtkins> fantasai: Woudln't the obvious container be the scroll container?<br> <Rossen_> ack f<br> <Zakim> fantasai, you wanted to queue up one other scrollbars issue which is Agenda+<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to react to smfr to ask why isn't the scroll container the sticky container<br> <TabAtkins> fantasai: you don't want it outside the scroll container<br> <emilio> `scrollbar-position: auto | sticky <margin>?` or something?<br> <TabAtkins> dbaron[m]: With sticky there's multiple bounds, I think I'm thinkinga bout another set<br> <TabAtkins> dbaron[m]: Say horiz scrollbar on a large table that's partially scrolled off<br> <TabAtkins> dbaron[m]: You want it to be on the bottom of the table but sticky to the screen<br> <TabAtkins> dbaron[m]: If the whole page has a horizontal scrollbar, you might not want these next to each other<br> <TabAtkins> dbaron[m]: Might want a slight separation<br> <TabAtkins> dbaron[m]: Two scrollbars adjacent to each other is generally bad, and this makes that easier to do<br> <TabAtkins> florian: also if your scroller is bigger in both dimensions, when you float it in it's still bigger; if they both float do they cross? dunno<br> <TabAtkins> emilio: Any platform with a primitive like this?<br> <TabAtkins> Rossen_: outside of panning, don't know of any<br> <TabAtkins> Rossen_: but outside of that, not sure what it means to ahve the ui primitive magicallys how up when you need it<br> <TabAtkins> Rossen_: So the amgic seems the bottom of the problem so far<br> <TabAtkins> florian: Possibly something to have a community iterate on proposals and then come back<br> <TabAtkins> Rossen_: To emilio's point, we don't know of native platforms that solve this in a graceful way today<br> <TabAtkins> Rossen_: And that's usually where these start<br> <TabAtkins> Rossen_: behaviors catch on from there<br> <TabAtkins> Rossen_: i'm more aligned with smfr here to just say "show us prior art" so we don't end up breaking things<br> <emilio> +1 to Rossen_<br> <TabAtkins> TabAtkins: Sounds reasonable to just close this down no change right now, and let convo continue if it comes up with something<br> <TabAtkins> Rossen_: Yeah don't want to disparage the use-case<br> <TabAtkins> dholbert: Maybe suggest to the OP to make sure that approaches make sense if things are nested multiple deep<br> <TabAtkins> dholbert: want to make sure they stack in a coherent way<br> <TabAtkins> Rossen_: Right, there's so many questions in this user interaction, I'm not gonna guess yet<br> <TabAtkins> flackr: is this possibly something scrollbar customization might let you do?<br> <TabAtkins> Rossen_: [repeating]<br> <TabAtkins> Rossen_: objections?<br> <toga> present-<br> <TabAtkins> RESOLVED: no change, happy to have discussion continue in-thread or elsewhere<br> <TabAtkins> florian: Leaving issue open so people can ahve good ideas<br> <TabAtkins> fantasai: so marking as deferred for this level then<br> <astearns> 6482<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2252#issuecomment-889473709 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 July 2021 21:29:56 UTC