- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Sep 2024 16:32:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scrollbars] Is the track visible in overlay scrollbars?`, and agreed to the following: * `RESOLVED: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> florian: A bit of an issue. With scrollbar-color, authors can (and must) specify two colors, one for the thumb and one for the track<br> <TabAtkins> florian: It's *the author's* responsibility to ensure that these colors ahve sufficient contrast so the scrollbar is visible and usable<br> <TabAtkins> florian: Problem is there's no cosntraint on what the UA can do with them.<br> <TabAtkins> florian: With overlay, there's many situations where the track isn't drawn at all<br> <TabAtkins> florian: So the author picked two contrasting colors, one might not be used, the other is used against a color they didn't anticipate<br> <TabAtkins> florian: So we gave the author a responsibility, without giving them assurances they're able to uphold it. that's a problem<br> <TabAtkins> florian: Several things could be done<br> <TabAtkins> florian: UAs could show the track all the time, could put a glow/border/shadow/outline around the thumb, they could do this only when they're not showing the track, they could test the contrast for the thumb against the content behidn it and only do the mitigations when needed<br> <chrishtr> q+<br> <flackr> q+<br> <TabAtkins> florian: Lots they could do, don't think we should mandate any particular one, but shoudl mandate they do *something*<br> <bramus> q+<br> <TabAtkins> florian: Because a white thumb on a black track, with a white background and no track, isn't good<br> <TabAtkins> florian: So I prefer to put a UA MUST in the spec, with a suggestion box giving some ideas for accomplishing it<br> <TabAtkins> florian: There's a bunch of options, just pick one that either allows both author colors to be there, or otherwise ensure contrast<br> <astearns> ack chrishtr<br> <TabAtkins> chrishtr: Agree it's infeasible to require a particular scrollbar UX, so I agree with the normative text suggestion that just requires some way to have contrast, with suggestions in informative text<br> <astearns> ack flackr<br> <TabAtkins> flackr: Agree as well, same general thing.<br> <PaulG> q+<br> <TabAtkins> flackr: May only be necessary to do this if the dev overrode the track color.<br> <TabAtkins> flackr: So we can say UAs can have a default transparent track color, and if the author overrode that, the UA must ensure contrast<br> <florian> q+<br> <astearns> ack florian<br> <TabAtkins> florian: So the author has to specify both colors right now<br> <TabAtkins> florian: You're saying if they happen to specify the same track color as what the UA would have done, they don't need to do anything special?<br> <TabAtkins> flackr: I didn't realize they both had to be specified. But yeah, if the author gives the same track as the UA, they UA doesn't need to do anything.<br> <TabAtkins> flackr: Maybe a bit unfortunate the author can't just specify a thumb color<br> <TabAtkins> florian: Reason we didn't allow just a thumb color is the author wouldn't know the track color, and wouldn't be able to ensure contrast.<br> <astearns> ack bramus<br> <TabAtkins> florian: But yeah, if they deliberately say a tranparent track, that's a reasonable exception to the "must provide contrast"<br> <TabAtkins> bramus: An alt to your B suggestion in the issue, is to give authors control to let them force rendering the track<br> <TabAtkins> bramus: Related to 9785, I needed to force-render the thumb<br> <TabAtkins> bramus: So like I *really* want a particular track color<br> <TabAtkins> florian: We could do that too, but as long as it's opt-in we still need what we're discussing here<br> <TabAtkins> florian: For the other case when the UA is still allowed to not draw the track.<br> <astearns> ack PaulG<br> <TabAtkins> PaulG: Is it possible to write a selector that lets author supply two contingencies, for thumb-with-track and for thumb-without?<br> <TabAtkins> PaulG: If that's the case, UA doesn't necessarily need to do heroics<br> <TabAtkins> florian: At the moment it's not possible. Could maybe add a MQ, but right now there's nothign<br> <emilio> 2+<br> <TabAtkins> PaulG: Okay, in general less magic is better, but if that's a longer/more difficult path, I understand the need for UAs to resolve it.<br> <emilio> q+<br> <florian> q?<br> <astearns> ack emilio<br> <TabAtkins> emilio: Regarding Bramus's comment, I think force-rendering the thumb is not great because it doesn't match platform conventions - it's weird for scrollbar-color to change how scrollbars work. Users still see familiar scrollbars.<br> <TabAtkins> emilio: So I'm fine with florian's proposal, but don't think we should force rendering bits.<br> <bramus> q+<br> <TabAtkins> emilio: Like in GTK Firefox will only render the thumb unless you're hovering the track, in which case the track will render too. That matches GTK behavior.<br> <TabAtkins> emilio: So I lik eFlorian's proposal that lets us pick a strategy to ensure contrast while staying within platform conventions<br> <astearns> ack bramus<br> <bramus> https://scroll-driven-animations.style/tools/scroll-timeline/params/<br> <TabAtkins> bramus: There are some use-cases, it's more like a design choice to actively show the scrollbars to make something clear. I'm dropping a demo<br> <TabAtkins> bramus: I really wanted to show the scrollbars always, even if you only have overlay<br> <TabAtkins> bramus: We don't need to continue the discussion, just saying there are use-cases<br> <smfr> q+<br> <TabAtkins> astearns: Yes, I think forcing scrollbar parts to be displayed is a separate issue<br> <astearns> ack smfr<br> <TabAtkins> smfr: I think forcing UA to do treatments on the thumb to make it visible is placing quite a burden on the UA.<br> <TabAtkins> smfr: In apple the scrollbars are rendered by UI Kit<br> <TabAtkins> smfr: Having them add shadows or glow or something is quite a burden<br> <florian> q+<br> <TabAtkins> smfr: I'm wondering if this puts the whole idea of author-controlled scrollbar colors at risk<br> <astearns> ack florian<br> <TabAtkins> florian: The proposal isn't that you have to adjust the thumb, it's that you have to do *something*. Maybe ignore *both* colors if that's fine.<br> <TabAtkins> florian: Maybe in the Apple case, currently that's fine. Earlier designs, thumb had texture and designs on it, would be visible regardless of color.<br> <smfr> q+<br> <TabAtkins> florian: But today's UI where the author can choose good colors and still not get a usable scrollbar isn't fine.<br> <TabAtkins> +1<br> <emilio> q+<br> <astearns> ack smfr<br> <TabAtkins> smfr: I always considered the colors as providing a base color and the UA can apply subtle effects on top of that<br> <TabAtkins> smfr: So if the UA can do not a flat color, that's ok<br> <TabAtkins> smfr: I think the issue is making sure the thumb is readable across different parts of the page, like a zebra stripe background.<br> <TabAtkins> smfr: So if the UA has flexibility with the colors that's fine<br> <astearns> ack emilio<br> <TabAtkins> florian: Yeah, that's mentioned already<br> <TabAtkins> emilio: We already take some liberties with the color to provide stuff like hover feedback<br> <TabAtkins> emilio: more directly to Simon's point, I think in Cocoa the thumb has a subtle outline, maybe semi-transparent. That might be enough already to conform to the requirement.<br> <TabAtkins> emilio: You'll still see the slight outline even with a matching background<br> <TabAtkins> emilio: So I think AppKit maybe does that already; we copied AppKit's scrollbar rendering and have code to do that, so you did it at some point<br> <florian> PROPOSED: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.<br> <TabAtkins> astearns: Not hearing sustained pushback. [outlines proposal]<br> <TabAtkins> chrishtr: So part of the normative text will say something about transparent?<br> <TabAtkins> florian: That wasn't in the original proposal, but was discussed here. If the author gives a transparent track they've already specified their thumb will match their background.<br> <TabAtkins> flackr: The author has provided two colors that should contrast, and the UA should maintain at least that contrast. If one is transparent, there's nothing for the UA to preserve.<br> <TabAtkins> chrishtr: So the UA will defer to the author about whether it actually contrasts.<br> <TabAtkins> flackr: yeah<br> <TabAtkins> chrishtr: Similar to if you make a white text on white bg, don't do that, not the UA'<br> <TabAtkins> smfr: Concerned about a transparent track, it can just be invisible then. Should be a provision for the UA to override colors if they're bad<br> <TabAtkins> florian: Already have that provision, including if the scrollbars just can't be customized.<br> <TabAtkins> astearns: At this point I think we should get the proposal into the draft and get feedback afterwards.<br> <TabAtkins> astearns: Concerns or objections?<br> <TabAtkins> RESOLVED: accept proposal as outlined in github, with an exception when the author explicitly sets a fully transparent track.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9855#issuecomment-2344135117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 September 2024 16:32:51 UTC