- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 24 Oct 2024 16:02:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-ui] Colors to use for appearance:base `<select>` ``, and agreed to the following: * `RESOLVED: Adopt ::check or ::checkmark for checkbox/radio checks` <details><summary>The full IRC log of that discussion</summary> <fantasai> RESOLVED: Adopt ::check or ::checkmark for checkbox/radio checks<br> <jarhar> https://github.com/w3c/csswg-drafts/issues/10909#issuecomment-2435550602<br> <gregwhitworth> jarhar: in this comment which I posted, I tried to take Tim's proposed colors for appearance: base and use them in select<br> <gregwhitworth> jarhar: the one thing that may not have been fully implemented is the background color for the popover/picker<br> <gregwhitworth> jarhar: do people like these, do you not like these? ntim does this meet what you were thinking?<br> <gregwhitworth> keithamus: I'm not super stoked about the border being currentcolore<br> <gregwhitworth> jarhar: why do you not like that?<br> <ntim> q+<br> <emilio> q+<br> <fantasai> background: Field; needs to be paired with background: FieldText; to ensure contrast<br> <gregwhitworth> keithamus: I don't think it's that prevelant and I think a lot of design systems will adjust them and if the currentcolor or textcolor which will impact the border color it will create more work for devs<br> <gregwhitworth> keithamus: I know it's probably controversial but there's opportunity to add a color keyword which will be preferable, akin to accent-color. That's what design systems do<br> <masonf> Wouldn't that be weird though because borders don't inherit?<br> <gregwhitworth> keithamus: we assign a custom property define a color but they rarely if ever attach to current color<br> <gregwhitworth> ack ntim<br> <fantasai> Note the initial value of `border-color` is `currentColor`<br> <gregwhitworth> ntim: we discussed this proposal internally and having a special keyword for border keyword is a default that ensures contrast. The only one that ensures contrast is currentColor<br> <gregwhitworth> ntim: I don't think this is really feasible<br> <gregwhitworth> jensimmons: if I understand what you were saying, is that it seems weird to authors have borders absorb currentColor and why would that change border colors<br> <gregwhitworth> jensimmons: I was on your side but we're really boxxed in here, what if we invented a new system color and not any of the above<br> <gregwhitworth> jensimmons: and we went down every rabbit hole, I hate it but I'm convinced<br> <gregwhitworth> jensimmons: I posted on mastadon and 70% of devs got it wrong<br> <fantasai> color = foreground color<br> <fantasai> therefore also the default border-color<br> <gregwhitworth> jensimmons: people think that color == text color when the whole color of the thing means the whole color except for the parts that you have changed<br> <gregwhitworth> jensimmons: if you set color to green then you use the pseudo to change text-color, etc<br> <gregwhitworth> jensimmons: I can't reproduce the convos we've had<br> <gregwhitworth> keithamus: I don't want to downplay them but some things jump out at me<br> <gregwhitworth> keithamus: you say 70% of devs got it wrong and we're going to follow the opposite of their intuition<br> <gregwhitworth> keithamus: we have the opportunity to get it right today and set us on a path to help them<br> <jensimmons> This was my survey on Mastodon: https://front-end.social/@jensimmons/113312399553267089<br> <gregwhitworth> keithamus: ntim said two things, but contrast function that allows us to ensure it so we could use that? And what contrast are we trying to adhere to here?<br> <jensimmons> q+<br> <gregwhitworth> keithamus: ntim you mentioned the background is transparent<br> <gregwhitworth> jensimmons: that was an argument I kept making, if they change the color of the background and they haven't yet changed the borders, they're going to change them<br> <gregwhitworth> jensimmons: there are other states like high-contrast mode that we can map to them then that something else needs to tie into it<br> <gregwhitworth> jensimmons: I didn't know high contrast mode existed on Windows and you can't test that on Mac<br> <gregwhitworth> jensimmons: there may be different ways to set this<br> <emilio> Button / ButtonText / ButtonBorder do exist already fwiw, and they do work as you expect.<br> <gregwhitworth> jensimmons: regarding the background being transparent; this is just an experiment and we should debate them and maybe they're not the right color. Everything else doesn't have a background unless you add it<br> <jensimmons> q-<br> <gregwhitworth> emilio: I was going to make the opposite point is that if you make the background transparent then you actually don't get the system colors and that seems a bit odd and the default should behave better than that<br> <gregwhitworth> emilio: we do have system colors that do map almost to what we want, and we could define them to have something consistent and add some states but we can make them work<br> <gregwhitworth> emilio: we can spec them to do the correct thing and high contrast works and you don't get the weird behavior where text colors impact border colors<br> <tantek> FYI: changing color sets the border-color by default is from CSS1 https://www.w3.org/TR/REC-CSS1/#border-color<br> <gregwhitworth> emilio: it's also how native buttons are styles already<br> <ntim> q+<br> <gregwhitworth> emilio: I just want to raise that if we go with transparent option we need to acknowledge that things like high contrast are not going to work like we expect<br> <gregwhitworth> zakim, close the queue<br> <Zakim> ok, gregwhitworth, the speaker queue is closed<br> <gregwhitworth> emilio: let's get some base colors and system keywords that do something sensible and don't do anything fancy and that gets the right behavior<br> <gregwhitworth> dbaron: there was a point that fantasai made in IRC about system colors and the more I think about the popup being a system color brings the whole philosophy into question<br> <gregwhitworth> dbaron: we want to only take the styles from the page and not have system colors, and the popup has to have a background as it will just overlap stuff and this proposal give a system color background and you have to match them in pairs and you need to ensure contrast in pairs<br> <emilio> +1<br> <gregwhitworth> dbaron: what fantasai said as well is that we need to give the popup a system color as well but is calling the whole philosophy as well. Maybe it's ok that the in page parts don't have these but the picker uses system colors for background<br> <gregwhitworth> q?<br> <emilio> ack dbaron<br> <gregwhitworth> ack ntim<br> <emilio> ack ntim<br> <gregwhitworth> ntim: to dbaron point, dialog and popover use system colors by default in the UA stylesheet<br> <gregwhitworth> ntim: it wouldn't be going away from what we have now and have the in page follow one paradigm and it wouldn't go against prior art. I agree with fantasai that we should use pairs in popup to have system background colors<br> <emilio> Right, but then the question is why not doing the same everywhere else (not just popups)?<br> <gregwhitworth> Zakim, end meeting<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10909#issuecomment-2435687231 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 24 October 2024 16:02:37 UTC