- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Apr 2024 00:03:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scrollbars] Is the track visible in overlay scrollbars?`. <details><summary>The full IRC log of that discussion</summary> <luke> q+<br> <fantasai> florian: Authors have no control, and can't figure out, if they have classic or overlay scrollbars<br> <fantasai> florian: when setting scrollbar colors, we require that they set two colors, and expect them to pick colors with good contrast<br> <fantasai> florian: what happens with overlay scrollbars is tricky: is the track even shown?<br> <fantasai> florian: what current browsers seem to do is, at rest, neither scrollbar thumb nor track shows at all<br> <fantasai> florian: if you start scrolling e.g. by flicking mousewheel or trackpad, then the thumb shows but not the track<br> <fantasai> florian: if you start interacting with scrollbars, then both show<br> <fantasai> florian: I think that's what all browsers do, but it's not specified<br> <fantasai> florian: If it's unspecified or undependable whether track is shown, how can we expect the author to pick good colors?<br> <fantasai> florian: if element backround and track are very different colors it's hard to ensure good contrast<br> <fantasai> florian: Browsers show track always for classic scrollbars, and sometimes for overlay<br> <fantasai> florian: If you use e.g. brightly colored track with pale thumb, it's usable for classic<br> <fantasai> florian: but can't see it well when not showing the track<br> <fantasai> florian: We could require that track is always shown<br> <fantasai> florian: or allow the UA to ensure good contrast when the track is not shown<br> <fantasai> florian: There's many complaints about this, I'm not sure entirely what is the best idea<br> <astearns> ack luke<br> <fantasai> luke: I don't think we can force-render the track in overlay mode<br> <fantasai> luke: it's OS-dependent how scrollbars behave<br> <fantasai> luke: one of the benefits of the standard scrollbar properties is keeping with the OS conventions<br> <fantasai> luke: Case where thumb is rendering and track isn't, the UA could step in and change the color<br> <fantasai> luke: spec allows some leeway already<br> <fantasai> luke: worth specifying, since we have an issue here<br> <schenney> q+<br> <fantasai> astearns: One option is to put something in the spec noting this case, if track not rendering then UA must ensure that the thumb is visible<br> <fantasai> astearns: and leave how that happens up to the UA<br> <fantasai> florian: That would be good<br> <fantasai> florian: true that UA has leeway in how to use colors, but not a spec violation to manage contrast -- currently claim it's the author's job to do it<br> <dholbert> q+<br> <fantasai> luke: One issue is touch devices, particularly mobile<br> <fantasai> luke: behavior of scrollbar on a phone is quite different than on a desktop<br> <fantasai> luke: on a phone, scroll indicator is not super useful, not something you're actively interacting with<br> <fantasai> luke: the mechanism is the touchscreen, and in those cases the UA might not need to do too much<br> <fantasai> florian: There are cases on desktop as well where you don't show anything<br> <fantasai> florian: but if you're trying to show, even as an indicator that you're not interacting with, still want to see it<br> <fantasai> florian: so "make it visible somehow" is relevant on mobile as well<br> <fantasai> florian: to the extent you're trying to show it at all<br> <astearns> ack schenney<br> <fantasai> schenney: with selection colors we said the UA shouldn't modify them<br> <fantasai> schenney: hesitant to say that UA can tweak colors here, because authors then can't specify definitively<br> <fantasai> schenney: hesitant to encourage UAs to change the colors<br> <fantasai> florian: With ::selection, author gets their background and their foreground<br> <fantasai> florian: if they get both colors but one of them is tweaked, then there's a problem<br> <luke> q+<br> <fantasai> florian: but here we're in situation where they will get only one of their colors<br> <flackr> q+<br> <fantasai> florian: in that situation, they're not getting both colors that they expect, then UA needs to do something<br> <fantasai> florian: goal is the same: to maintain good contrast<br> <fantasai> florian: mechanics are different<br> <fantasai> schenney: true, the situation is different<br> <fantasai> astearns: I could see a UA deciding, for this case where they're not going to render the track, to render the thumb with the specified color with some kind of outline of the track color<br> <fantasai> astearns: but I wouldn't want to specify that, since that wouldn't be appropriate on all OSes<br> <astearns> ack dholbert<br> <fantasai> dholbert: wanted to ask, if white background and white scrollbar thumb, and expecting it to render on some other color<br> <fantasai> dholbert: unsure if browser can make that visible without some guidance<br> <fantasai> dholbert: focus ring is reasonable idea to the extent that it fits with the look and feel of scrollbars<br> <florian> q?<br> <fantasai> dholbert: might increase contrast slightly if there's some to begin with, but if the colors are identical... I'm stuck to think what's a good way to handle it<br> <astearns> ack luke<br> <fantasai> luke: Agree, if property specifies color, should just use that color<br> <fantasai> luke: at the same time have case with e.g. accent-color where it can change how things are rendered<br> <florian> q+<br> <fantasai> luke: we do have algorithm to come up with contrasting glyph<br> <fantasai> luke: idk if specified or just largely interoperable incidentaly<br> <fantasai> luke: but could come up with some kind of algorithm for colors<br> <masonf> q+<br> <fantasai> luke: I know WebKit in particular leaves scrollbars to platform SDK, can't even change colors<br> <fantasai> luke: do think it's worthwhile specifying that browsers should deal with this case<br> <fantasai> luke: even if we can't come up with a must<br> <astearns> ack flackr<br> <fantasai> flackr: I'm concerned, in cases where we know the background color it applies<br> <fantasai> flackr: but default is that most things have transparent background<br> <fantasai> flackr: so paint on top of ... something<br> <fantasai> flackr: do browsers then have to figure out what's underneath?<br> <fantasai> astearns: [example of passing through a zone of color] Do you have to change the color as you go?<br> <astearns> ack florian<br> <fantasai> florian: comparison with accent-color doesn't work, because you specify a single color<br> <fantasai> florian: which is applied to something with geometry<br> <fantasai> florian: and UAs often do [something], and one of these lines at least will be visible<br> <fantasai> florian: situation is different. Scrollbars now don't have multiple colors, they're flat<br> <fantasai> florian: also specifying a pair of colors<br> <fantasai> florian: can't really respect "the thing" because we're ignoring half of it<br> <fantasai> florian: given we say authors are responsible for contrast, if the UA ignores half of what author is saying sometimes<br> <fantasai> florian: then UA must do something to ensure contrast<br> <fantasai> florian: things we could do:<br> <fantasai> florian: * ignore the author colors in thumb-only mode entirely<br> <luke> Yeah that's not a bad idea actually, treat it as auto value in that case<br> <fantasai> florian: or * [missed next example]<br> <fantasai> florian: or do some kind of pixel inversion<br> <fantasai> florian: or tint the color based on what's below it<br> <fantasai> florian: I don't think we should specify any of them, but require something<br> <fantasai> florian: which one you pick might be different based on OS<br> <fantasai> florian: but leaving case where author did something reasonable, but scrollbar is entirely invisible, doesn't seem OK<br> <fantasai> astearns: concern I have with dropping both colors and going with platform defaults is that there may be cases where designer does have a good contrasting color<br> <fantasai> astearns: it should be only if the specified color doesn't provide sufficient contrast<br> <fantasai> florian: what sufficient contrast is is UA defined, no clear boundaries<br> <dandclark> fantasai: The problem is that the UA can't easily tell what the color is because it's often transparent. Could be many different things. So don't know if that's particularly doable to check the contrast with what you can't see.<br> <fantasai> florian: allowed to make it conditional, but don't have to require it<br> <astearns> ack masonf<br> <fantasai> mfreed: Wrt accent-color, spec doesn't require an algorithm, just requires maintaining contrast<br> <fantasai> mfreed: algorithm in Blink/Gecko is probably the same because we worked together<br> <fantasai> luke: if we just drop the fun color, in iOS/Android you never draw the track<br> <florian> q+<br> <fantasai> luke: so I think it does need to be conditional on something<br> <astearns> ack florian<br> <fantasai> florian: I don't think we would require you to ignore the thumb color, just have to make it visible somehow<br> <fantasai> florian: This is not "do this particular thing", just "do something"<br> <fantasai> astearns: We could put a SHOULD requirement, if you're not showing the track and you either can determine that the specified thumb color would not have sufficient contrast or you cannot determine the contrast, then browsers should ignore the specified thumb color<br> <fantasai> florian: uncomfortable with SHOULD<br> <dandclark> fantasai: We don't have good answers here.<br> <fantasai> florian: there is a good answer, just paint the track<br> <fantasai> flackr: or paint a contrasting outline<br> <fantasai> florian: either it's solveable, so shoud be MUST, or it's not, in which case we need a better idea<br> <dandclark> fantasai: Do we want to allow UA to use the track color instead of thumb color?<br> <fantasai> florian: sure why not<br> <fantasai> luke: that might not guarantee contrast<br> <fantasai> luke: shouldn't disallow from doing that<br> <fantasai> astearns: we're over time, take back to issue<br> <fantasai> astearns: see if there is some sort of MUST processing that we can agree on<br> <fantasai> astearns: I don't think we're there yet<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-2035828520 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 April 2024 00:03:23 UTC