[css-ui] Colors to use for appearance:base <select>

[josepharhar]

In this issue, I proposed using system colors like Field and FieldText in the UA stylesheet. However, it was brought up that "There are alternatives that work in dark mode that don't involve light-dark() / system colors, while allowing easy overrides."

What foreground/background colors should we put in the UA stylesheet?

[LeaVerou]

field and fieldtext should be responsive to dark/light mode by default, just like other system colors (e.g. canvas and canvastext).

And given the proposal to override system colors with page-specific design tokens (see #9660), it seems like system colors are absolutely the right choice here. Curious what alternatives @nt1m had in mind, because I can't think of any that don't involve either system colors or light-dark().

[nt1m]

I presented this at TPAC:

• transparent background
• inherit color/font/etc.
• border-color: currentColor

[LeaVerou]

@nt1m what color would the dropdown have? Transparent?

[nt1m]

I think the picker would have to use system colors, since it can't be transparent.

[LeaVerou]

I’m confused; isn’t this what @josepharhar is proposing? 🤔

[nt1m]

The in-page control would use #10909 (comment) , the picker would use system colors.

[LeaVerou]

Oh agreed on that (except border-color: currentcolor would be too harsh, so maybe something like lab(currentcolor l a b / 50%))

[josepharhar]

Proposed resolution: use tim's proposed colors for base appearance select, with a system color for the popover's background color:

select {
  border: 1px solid currentColor;
  background-color: color-mix(in lab, currentColor 10%, transparent);
  color: inherit;
}
select:enabled:hover {
  background-color: color-mix(in lab, currentColor 20%, transparent);
}
select:enabled:active  {
  background-color: color-mix(in lab, currentColor 30%, transparent);
}
::picker(select) {
  border: 1px solid rgba(0, 0, 0, 0.15);
  background-color: Field;
}

[css-meeting-bot]

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

The full IRC log of that discussion

<fantasai> RESOLVED: Adopt ::check or ::checkmark for checkbox/radio checks
<jarhar> https://github.com//issues/10909#issuecomment-2435550602
<gregwhitworth> jarhar: in this comment which I posted, I tried to take Tim's proposed colors for appearance: base and use them in select
<gregwhitworth> jarhar: the one thing that may not have been fully implemented is the background color for the popover/picker
<gregwhitworth> jarhar: do people like these, do you not like these? ntim does this meet what you were thinking?
<gregwhitworth> keithamus: I'm not super stoked about the border being currentcolore
<gregwhitworth> jarhar: why do you not like that?
<ntim> q+
<emilio> q+
<fantasai> background: Field; needs to be paired with background: FieldText; to ensure contrast
<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
<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
<masonf> Wouldn't that be weird though because borders don't inherit?
<gregwhitworth> keithamus: we assign a custom property define a color but they rarely if ever attach to current color
<gregwhitworth> ack ntim
<fantasai> Note the initial value of `border-color` is `currentColor`
<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
<gregwhitworth> ntim: I don't think this is really feasible
<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
<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
<gregwhitworth> jensimmons: and we went down every rabbit hole, I hate it but I'm convinced
<gregwhitworth> jensimmons: I posted on mastadon and 70% of devs got it wrong
<fantasai> color = foreground color
<fantasai> therefore also the default border-color
<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
<gregwhitworth> jensimmons: if you set color to green then you use the pseudo to change text-color, etc
<gregwhitworth> jensimmons: I can't reproduce the convos we've had
<gregwhitworth> keithamus: I don't want to downplay them but some things jump out at me
<gregwhitworth> keithamus: you say 70% of devs got it wrong and we're going to follow the opposite of their intuition
<gregwhitworth> keithamus: we have the opportunity to get it right today and set us on a path to help them
<jensimmons> This was my survey on Mastodon: https://front-end.social/@jensimmons/113312399553267089
<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?
<jensimmons> q+
<gregwhitworth> keithamus: ntim you mentioned the background is transparent
<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
<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
<gregwhitworth> jensimmons: I didn't know high contrast mode existed on Windows and you can't test that on Mac
<gregwhitworth> jensimmons: there may be different ways to set this
<emilio> Button / ButtonText / ButtonBorder do exist already fwiw, and they do work as you expect.
<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
<jensimmons> q-
<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
<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
<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
<tantek> FYI: changing color sets the border-color by default is from CSS1 https://www.w3.org/TR/REC-CSS1/#border-color
<gregwhitworth> emilio: it's also how native buttons are styles already
<ntim> q+
<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
<gregwhitworth> zakim, close the queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<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
<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
<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
<emilio> +1
<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
<gregwhitworth> q?
<emilio> ack dbaron
<gregwhitworth> ack ntim
<emilio> ack ntim
<gregwhitworth> ntim: to dbaron point, dialog and popover use system colors by default in the UA stylesheet
<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
<emilio> Right, but then the question is why not doing the same everywhere else (not just popups)?
<gregwhitworth> Zakim, end meeting

[josepharhar]

@nt1m what do you think we should do? Use transparency and currentColor for the in-page part and system colors for the picker? Or system colors for everything? Or something else?

[nt1m]

On a personal level, I still favor the first option. It's unopinionated and matches other HTML elements:

• <div>/other in-page elements use transparent backgrounds/currentColor (in-page form controls)
• <dialog>/popover use system colors (::picker falls into this category)

[josepharhar]

Thanks! How do these colors look? I made ::picker match the colors used for dialog and popover.

/* Rules on select won't apply when select has a child button
 * because button already has borders, colors, and active/hover. */
select {
  border: 1px solid currentColor;
  background-color: color-mix(in lab, currentColor 10%, transparent);
  color: inherit;
}
select:enabled:hover {
  background-color: color-mix(in lab, currentColor 20%, transparent);
}
select:enabled:active  {
  background-color: color-mix(in lab, currentColor 30%, transparent);
}
::picker(select) {
  color: CanvasText;
  background-color: Canvas;
  border: solid;
}

Should we also have :disabled colors? Perhaps by setting color or opacity?

[emilio]

I'd prefer something like:

select {
  border: 1px solid ButtonBorder;
  background-color: Button;
  color: ButtonText;

  &:enabled:hover {
    background-color: ButtonHover; /* new */
    color: ButtonHoverText; /* new */
  }
  &:enabled:active {
    background-color: ButtonActive; /* new */
    color: ButtonActiveText; /* new */
  }
}

Or so, where we define those colors to be something sensible.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Colors to use for appearance:base `<select>` .

The full IRC log of that discussion

<chrishtr> jarhar: last time we talked about this issue I tried to loop in Tim's proposed styles for buttons for appearance:base into selecct
<chrishtr> jarhar: also talked about system colors and contrast, and the picker
<chrishtr> jarhar: since then I've posted some styles that used Tim's proposed colors for in-page and system colors for picker
<chrishtr> jarhar: thought these would be reasonable defaults
<chrishtr> jarhar: Emilio proposed an alternative about system colors
<chrishtr> jarhar: I don't have strong opinions but would like to choose something
<ntim> q+
<astearns> ack ntim
<chrishtr> jarhar: Emilio liked system colors because it ensures contrast with all the modes
<chrishtr> ntim: my original suggestion of using currentcolor and transparency was to make in-page controls as easy to style as a blank div
<chrishtr> ntim: for the picker, we can't use transparency. think we should use system colors there. Dialogs and popovers use them by default also.
<chrishtr> ntim: everything I've proposed is consistent with other things in HTML
<emilio> q+
<astearns> ack emilio
<chrishtr> emilio: The main reason why I think system colors could be worth it is that it works with color scheme and forced colors.
<chrishtr> emilio: Also don't think it would be not too hard to do it. But don't object to using currentcolor etc
<masonf> q+
<astearns> ack masonf
<chrishtr> masonf: I think we should aim for having a thing that is easiest to understand, since developers are likely to override anyway.
<jensimmons> q+
<astearns> ack fantasai
<chrishtr> masonf: weakly in favor of what Emilio is proposing for that reason
<chrishtr> fantasai: the currentcolor approach is more minimal I think
<masonf> In devtools, they'll see that background-color is `color-mix(in lab, currentColor 10%, transparent)`
<jensimmons> 100% developers do not know that system colors exist. They will assume these are defined colors in the UA stylesheet.
<chrishtr> fantasai: they get colors either way, but fewer with currentcolor, so I think it's easier for them to override just that one
<astearns> ack jensimmons
<chrishtr> jensimmons: there are different groups of colors: text, borders, bits and pieces
<chrishtr> jensimmons: why are the backgrounds of my form a certain color?
<chrishtr> jensimmons: as soon as they change the color of the page it'll show a difference for their form
<chrishtr> jensimmons: nothing else on the page comes with a background color, so I think it's better for this to not have one eother
<keithamus> q+
<astearns> q+
<chrishtr> jensimmons: like the idea of a transparent background
<emilio> q+
<chrishtr> jensimmons: it's busywork to have to change that
<chrishtr> jensimmons: this makes them feel a pain in the ass to style
<astearns> ack keithamus
<chrishtr> keithamus: dialogs and popovers have canvas as the background color
<chrishtr> keithamus: my preference would be system colors
<astearns> ack astearns
<chrishtr> astearns: I wonder if using transparency would get us into problems with contrast
<astearns> ack emilio
<annevk> I think dialog and popover are different in that they are displayed in the top layer.
<annevk> Form controls are not.
<chrishtr> emilio: it doesn't necessarily cause contrast issues unless you use background images
<jensimmons> Yes, canvas and dialog have backgrounds. That makes sense. Form controls don't feel special — like they should be part of the page... they are elements on the page. Where dialog — well, of course it has a color. Just like the body itself. It's a thing, that needs a background.
<chrishtr> emilio: I think native app design systems do have background colors on their form controls?
<ntim> material design :)
<astearns> ack fantasai
<chrishtr> fantasai: is there a precedent for toolkits with transparent backgrounds?
<jensimmons> What's also super important is thinking through how authors will override the colors. How will they change each, and what else does that affect?
<chrishtr> fantasai: if we go with system colors we'd have to define more of them
<chrishtr> fantasai: different systems also display select elements differently
<chrishtr> keithamus: system colors are an abstraction away from color mixing, but we're presumably sticking to one style
<chrishtr> emilio: nothing prevents us from mixing to currentcolor
<chrishtr> fantasai: system colors require contrast, but currrentcolor doesn't know what it is mixing with?
<chrishtr> fantasai: needs contrast be\tween system colors
<fantasai> (can't compute a system color to transparent)
<fantasai> +1 to understanding the developer experience better

[josepharhar]

I talked to @nt1m about colors for disabled and here is an option:

select:disabled {
  color: color-mix(in srgb, currentColor 50%, transparent);
}

[josepharhar]

We also need colors for options. Similar to buttons, we could have these rules:

select option:enabled:hover {
  background-color: color-mix(in lab, currentColor 20%, transparent);
}
select option:enabled:active {
  background-color: color-mix(in lab, currentColor 30%, transparent);
}
select option:disabled {
  color: color-mix(in lab, currentColor 50%, transparent);
}

[emilio]

Using currentcolor for backgrounds seems not great if we're using it for foreground too. I'd much rather use light-dark(rgba(0, 0, 0, .05), rgba(255, 255, 255, .1)) or so.

In any case, I'd still much rather use system colors and define those to compute as such mixes, except in forced colors mode, where they'd work.

[nt1m]

Using currentcolor for backgrounds seems not great if we're using it for foreground too. I'd much rather use light-dark(rgba(0, 0, 0, .05), rgba(255, 255, 255, .1)) or so.

That seems reasonable to me.

In any case, I'd still much rather use system colors and define those to compute as such mixes, except in forced colors mode, where they'd work.

As @fantasai mentioned, you don't want to affect other uses of system colors on the page.

An alternative that might work for everyone is to use system colors behind a forced-colors media query.

[emilio]

As @fantasai mentioned, you don't want to affect other uses of system colors on the page.

Can either of you elaborate? Do you mean we don't want to change existing system color behavior? If so that's fine tho, right? We can add new ones, or am I missing something?

[nt1m]

As @fantasai mentioned, you don't want to affect other uses of system colors on the page.

Can either of you elaborate? Do you mean we don't want to change existing system color behavior? If so that's fine tho, right? We can add new ones, or am I missing something?

We can't change the existing ones at least. People expect combinations like ButtonFace / ButtonText to consistently contrast and to be opaque in all modes/situations (including when overlaying a background-image) if they use them on other elements than form controls. If we re-map those to transparent colors, these assumptions no longer hold.

Introducing new keywords is an option, but I don't think it's a great one, mainly because it's harder to understand due to the extra indirection, and makes it less tempting to use the defaults.

If forced colors mode is the main concern, can't we just force the system colors when this is enabled? The mechanism to do this is up to the implementor, could be a media query inside the UA stylesheet, could be a -internal-base-forced-colors function, etc... I'm not convinced we should introduce new keywords for the sake of forced colors mode.

[emilio]

Well, if we're going to need system colors anyways for forced colors (even if it's on a UA sheet), I don't see the point in having two different sets of styles.

[emilio]

Forced colors is indeed the main concern. color-scheme could be another, but maybe we just use light-dark or somesuch for backgrounds and things work out

[nt1m]

Well, if we're going to need system colors anyways for forced colors (even if it's on a UA sheet), I don't see the point in having two different sets of styles.

It's just easier to teach developers when you don't have magical color keywords.