Re: [csswg-drafts] [css-ui] Colors to use for appearance:base `<select>` (#10909)

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

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 7 November 2024 17:04:29 UTC