- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Mar 2024 17:02:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scrollbars] What do (semi) transparent colors mean for scrollbar-color`. <details><summary>The full IRC log of that discussion</summary> <fantasai> florian: Spec doesn't say what happens to transparent/semi-transparent colors if you specify them<br> <fantasai> florian: you could ignore the alpha channel<br> <fantasai> florian: or pre-composite against some color, maybe white, maybe white or black depending on 'color-scheme'<br> <fantasai> florian: maybe transparent thumb over track is possible, but track is opaque<br> <fantasai> florian: variety of possible options<br> <fantasai> florian: e.g. emilio just mentioned making thumb and track invisible<br> <fantasai> florian: but what about partially transparent?<br> <fantasai> florian: does the non-colored part of the scrollbar also become invisible?<br> <fantasai> florian: there's no requirement that scrollbar contains only thumb and track<br> <fantasai> florian: but in the past, and in some systems still, scrollbars could have up/down buttons as well<br> <fantasai> florian: do these become invisible as well?<br> <flackr> q+<br> <emilio> q+<br> <fantasai> florian: which options seem reasonable?<br> <fantasai> florian: Lea commented that alpha channel shouldn't be ignored<br> <fantasai> florian: suggested pre-composing against white/black<br> <astearns> ack flackr<br> <fantasai> florian: or 'canvas', is equivalent to lack/white?<br> <fantasai> emilio: not necessarily<br> <fantasai> flackr: Color used for thumb makes sense to apply to other buttons<br> <fantasai> flackr: maybe make that explicit?<br> <fantasai> flackr: for transparency, I can see use-cases for semi-transparent thumbs<br> <fantasai> flackr: maybe make them look frosted or osmething<br> <fantasai> flackr: maybe keeping their transparency to some extent allowed<br> <fantasai> flackr: but I don't think the rest of the scroll controls should be made more transparent<br> <fantasai> flackr: UA should be free to make it clear that the scroll thumb is there<br> <fantasai> flackr: to be interacted with<br> <astearns> ack emilio<br> <florian> q+<br> <fantasai> emilio: I also have a preference to not special-case transparency<br> <fantasai> emilio: let stuff be semi-transparent as much as the UA can deal with it<br> <fantasai> emilio: is there a good reason to not do that?<br> <fantasai> florian: Here, we're charging to supply both the foreground and background, and thereby ensuring good contrast<br> <PaulG> q+<br> <fantasai> florian: They need to know if the alpha channel will be ignored, composed against lack/white, or against content below?<br> <ntim> +1 to "as the UA can deal with it", some system frameworks may not support it<br> <fantasai> florian: whichever one we choose, needs to be consistent so author can choose properly contrasting colors<br> <astearns> ack emilio<br> <astearns> ack florian<br> <TabAtkins> fantasai: I agree withi everythign florian said<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: ADditional point, let's say you decide to honor the color *and* transparency<br> <TabAtkins> fantasai: And on one system they use black scrollbars, just an oval on a rectangle, flat color, no distinguishing features<br> <TabAtkins> fantasai: If you make both thumb and track transparent, it's invisible<br> <TabAtkins> fantasai: But on another system there's an aqua effect, 3d with some shading<br> <TabAtkins> fantasai: That shading will exist on a fully transparent bar<br> <TabAtkins> fantasai: So on that page the scrollbar will still be visible, just "clear"<br> <TabAtkins> fantasai: So I think we need some kidn of consistency so when an author gets one effect vs the other...<br> <TabAtkins> fantasai: So if they dev on Mac OS 2001 it looks good, but Mac 2011 you can't see anything at all...<br> <florian> q?<br> <TabAtkins> fantasai: So whethe rit's visible and has enough contrast varies depending on style, if you honor transparent colors<br> <TabAtkins> fantasai: So we need to make sure an author working on one platform can know whether their styles will make a visible or invisible scrolblar, on all platforms<br> <astearns> ack PaulG<br> <florian> q+<br> <emilio> q+<br> <fantasai> PaulG: I brought up with APA, they offered to help with the language<br> <fantasai> PaulG: and ensuring contrast/affordances etc.<br> <fantasai> PaulG: Consistency helps everyone, but even if not consistent, APA is comfortable going forward as long as articulated<br> <astearns> ack florian<br> <fantasai> florian: Given fantasai's argument, that pushes us towards precomposing, to get you reliable colors<br> <fantasai> florian: you could still end up with white-on-white and black-on-black and have that be visible with shading and invisible otherwise<br> <astearns> ack emilio<br> <fantasai> florian: but if doing foreground and background are the same, you'll have issues on some platforms -- most platforms currently<br> <fantasai> emilio: I think we should at least specify that if you provide 0 alpha channel, then the whole thing is transparent, because that's a reasonable use case<br> <fantasai> florian: why? why not use other ways of making invisible<br> <kizu> q+<br> <fantasai> emilio: same as having any element invisible<br> <fantasai> emilio: use case was showing scrollbar on :hover without layout shift. You can do with scrollbar gutter nowadays but still useful to not have to do any layout to show a scrollbar<br> <fantasai> emilio: I don't think we need to specify semitransparent colors super deeply<br> <fantasai> emilio: forcing you to compose on a flat color, that's a bit weird.<br> <fantasai> emilio: E.g. on linux/firefox you only show thumb. Track is mostly transparent.<br> <florian> q+<br> <fantasai> emilio: I think we should leave the rendering of most of these semitransparent colors up to UA and how they can provide a good scrollbar with what they get<br> <astearns> ack fantasai<br> <fantasai> fantasai: If we want invisible scrollbars, have a keyword for that. Transparent won't guarantee invisible scrollbars<br> <fantasai> emilio: I don't feel super strongly, but fading a scrollbar by animating alpha channel is nice<br> <TabAtkins> fantasai: if scrollbar is shared, it'll aniamte from clear to purple or wahtever, it just won't actuallyb e invisible because the shading will be there<br> <fantasai> emilio: I don't think current platforms do shading<br> <astearns> s/shared/shaded/<br> <fantasai> emilio: if fully transparent is actually invisible, then the animation would work in such a platform<br> <flackr> q+<br> <astearns> ack kizu<br> <fantasai> kizu: Maybe this could be considered alongside another issue, 9855 about the track and overlay scrollbars and setting colors<br> <fantasai> kizu: if we could require UAs to make the thumb and track to always have contrast, we should do it<br> <fantasai> kizu: and then we might make an exception for completely transparent scrollbars for authors that want to make it completely invisible but still take space<br> <fantasai> kizu: I'm not sure if we want to provide this use case, or always want hidden scrollbars [missed]<br> <fantasai> kizu: issue with making this a special case is that it might not work for UAs for transitions, if you want to have scrollbar appear if UA chooses to precompose colors against some other colors<br> <fantasai> kizu: if we precompose completely invisible, at zero it disappears immediately. That's maybe an issue<br> <astearns> ack florian<br> <fantasai> florian: I'm open to a variety of option, but what is not reasonable is to not specify<br> <fantasai> florian: if the author can't know if precomposed over white or black or actual element background, they can't ensure their colors provide contrast<br> <fantasai> florian: because they don't know what their colors mean<br> <fantasai> florian: so we can't allow one or the other, we have to pick one.<br> <fantasai> florian: Emilio is leaning towards "don't precompose"<br> <fantasai> florian: Another question in another issue about whether you're required to paint the track at all in overlay scrollbars, hoping to keep separate<br> <emilio> q+<br> <astearns> ack flackr<br> <fantasai> florian: desire that you see things the same suggests an alternative, require that we use the opacity from the color for the rest of the painting even if it is shaded<br> <ntim> Some system frameworks don't support alpha, so if we specify anything i'd rather have it be simple<br> <fantasai> s/florian/flackr/<br> <fantasai> flackr: unsure if that's ideal, but would allow things to fade consistently<br> <fantasai> flackr: but maybe if fully transparent don't want it to hit test either<br> <fantasai> flackr: so maybe separate property<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: If fading the scrollbar is something people really want, we shoul dhave scrollbar-opacity that controls it all, including the parts the author isn't coloring<br> <TabAtkins> fantasai: Lots of things potentially in a scrollbar that potentially aren't under author control<br> <astearns> ack emilio<br> <TabAtkins> fantasai: But downside of making it transparent when not hovering - if the element has focus but not hovering, and someone assuming it's only scrolalble when there are scrollbars, someone using a differnet mechanism won't know it's scrolalble<br> <florian> qq+<br> <fantasai> emilio: similar thing with accent-color, and e.g. Chromium ignores alpha channel, Firefox tries to deal with it, and unsure about WebKit<br> <ntim> AppKit doesn't support changing scrollbar colors, so neither does WebKit<br> <fantasai> florian: answer might be the same, but for accent-color, it is different because in that case the author is only providing one color -- UA is charged with providing good contrast<br> <emilio> *?<br> <fantasai> florian: but for scrollbars, the author needs to ensure contrast<br> <fantasai> florian: Either UA ensures contrast, or we specify how the colors composite so the author can know whether they get good contrast<br> <astearns> ack florian<br> <Zakim> florian, you wanted to react to emilio<br> <bramus> q?<br> <fantasai> astearns: I think I'm convinced that we should not try to solve the fully-transparent case with scrollbar colors because there are other bits of the scrollbar which may not be under these colors' control<br> <fantasai> astearns: I find that logic compelling<br> <ntim> WebKit does ignore alpha for accent-color<br> <fantasai> florian: if we go that way, then do we specify semi-transparent colors to be pre-composed? I think these two go together...<br> <fantasai> astearns: yes, but less convinced about that<br> <fantasai> astearns: Anyone want to argue for ignoring alpha channels in scrollbar colors entirely?<br> <fantasai> florian: What you propose seems reasonable, may be other options<br> <ntim> pre-composing is hard because we don't know what background to use<br> <fantasai> astearns: 2 options are ignoring or pre-composing<br> <fantasai> fantasai: Lots of points brought up in this discussion, might be good to list the good options and pros/cons, and resolve later<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9853#issuecomment-2010073356 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 March 2024 17:02:44 UTC