[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.

[josepharhar]

For options: If we used system colors instead of color-mix() like my last comment, we could use SelectedItem/SelectedItemText or AccentColor/AccentColorText

[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.

Circling back to this, on second thought, I actually prefer color-mix() with currentColor. light-dark(rgba(0, 0, 0, .05), rgba(255, 255, 255, .1)) has no guarantee of being visible against the background, whereas color-mix() tinted with currentColor is guaranteed to be shown (unless someone changes the foreground to be the same as the background)

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Colors to use for appearance:base `<select>` , and agreed to the following:

• RESOLVED: Use currentColor for borders, inherit the color, transparent background color (for in-page controls). Use system colors for pickers.

The full IRC log of that discussion

<gregwhitworth> ntim: presenting a presentation on proposed colors
<gregwhitworth> q?
<masonf> q+
<gregwhitworth> ack masonf
<gregwhitworth> masonf: thank you for the preso and history lesson
<gregwhitworth> masonf: my question is about forced colors and I assumed we would need the MQ but it seems like you found we may not need to do that?
<gregwhitworth> ntim: it's always ensured with currentcolor and transparent background
<dbaron> The resolution https://github.com//issues/11097#issuecomment-2489223857 from yesterday might be relevant here
<gregwhitworth> ntim: you don't get the semantic colors that the user has defined
<gregwhitworth> q?
<gregwhitworth> dbaron: yesterday the CSSWG had a discussion around forced-color and color-mix and it doesn't allow you to override the colors as it falls back to the set
<gregwhitworth> ntim: that may mean that we don't need the special color
<brecht_dr> q+
<gregwhitworth> dbaron: the flip side is the risk that in forced colors mode there is no way to identify disabled style
<gregwhitworth> ack fantasai
<Zakim> fantasai, you wanted to request a copy of the slides for the minutes
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: the one example you showed us with the one covered in yellow
<gregwhitworth> brecht_dr: I'm curious if this works but is this something that can be annoying that you're using this in forced colors?
<gregwhitworth> brecht_dr: I don't know but I would like to know as this would be annoying
<gregwhitworth> ntim: the idea is not only for HC but also for cognitive disability for instance everything that is blue is a button
<gregwhitworth> ntim: everything that is green is a text input, etc
<gregwhitworth> ntim: the user preference is the thing to respect here regardless
<masonf> q+
<gregwhitworth> ntim: we want to force system colors in forced-colors mode and the theory of how is to just do what works
<gregwhitworth> ack masonf
<gregwhitworth> masonf: the first one is the proposal about transparency and currentcolor and system colors
<argyle> q+
<gregwhitworth> ack argyle
<gregwhitworth> argyle: I'm curious if this proposal that we would like ghost styling for all form inputs as though it's a div with a border and would have no background
<gregwhitworth> fantasai: correct
<gregwhitworth> masonf: by default, of course the dev could add one
<gregwhitworth> argyle: we have colors in system colors
<gregwhitworth> fantasai: but none that are garaunteed to have contrast with system colors
<gregwhitworth> q+
<gregwhitworth> masonf:
<gregwhitworth> masonf: what is the problem
<gregwhitworth> argyle: I see more issues with this than currentcolor with system colors than this
<gregwhitworth> fantasai: it's the background that is underneath unless you change the color on the input
<gregwhitworth> fantasai: you can get into this today
<gregwhitworth> fantasai: you can set the color without setting the background color today and true since CSS1
<gregwhitworth> argyle: I would have assumed everything is accessible by default
<gregwhitworth> argyle: it comes with healthy defaults for background + text, etc
<ntim> PROPOSED RESOLUTION: Use currentColor for borders, inherit the color, transparent background color (for in-page controls). Use system colors for pickers.
<ntim> We force system colors in forced colors mode, figure out what would be the best mechanism.
<gregwhitworth> fantasai: you'll get this if you set the color to the background that doesn't contrast with the background
<gregwhitworth> argyle: I don't know a design system that is ghost alone
<gregwhitworth> ntim: Material Design
<gregwhitworth> ntim: the proposal inherits the color from the parent element
<gregwhitworth> argyle: they have an inherited contrast and they could have good contrast out of the box
<gregwhitworth> anne: none of the HTML elements have their own background
<gregwhitworth> anne: that's the reasoning behind this proposal
<gregwhitworth> anne: isn't that the point of this
<gregwhitworth> argyle: I thought the principle was to make this "safe" and accessible by default
<gregwhitworth> fantasai: what is the difference between this and an H3
<gregwhitworth> argyle: I'm not saying they're the same
<fantasai> or a <strong> element
<gregwhitworth> anne: they have the same requirements
<gregwhitworth> anne: how are they different
<gregwhitworth> argyle: they have states and interactivity
<gregwhitworth> argyle: they're quite different
<brecht_dr> q+
<gregwhitworth> anne: none of those impact the styles
<gregwhitworth> ntim: people expect backgrounds behind them is that we expect them and there is no extra background requirement
<davidleininger> q+
<chrishtr> q+
<gregwhitworth> argyle: if you want to go super minimal and that's the most minimal starting place and you're saying people will fix it
<gregwhitworth> fantasai: if it's not they have bigger problems
<jarhar> q?
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: I do think it's important to have base because you decided to set it to that but I do understand from argyle and differentiation from that and a div
<gregwhitworth> brecht_dr: if you have a border on an H3 and an interactive element right from the start
<gregwhitworth> brecht_dr: I'm not sure if that is right
<gregwhitworth> fantasai: we don't have a border on H3 on it
<masonf> On a white background, that's the case today though.
<gregwhitworth> fantasai: maybe you want to make some style changes then
<gregwhitworth> brecht_dr: I agree on that
<fantasai> +1 masonf
<gregwhitworth> brecht_dr: you want something is contrasted and not contrasted
<chrishtr> qq+
<masonf> gregwhitworth: when we kicked off appearance:base, the styles will be interoperable. That was fundamental.
<dandclark> q+
<masonf> gregwhitworth: when you do appearance:base, you know how everything will be. We did a lot of research on forced contrast. In theory, even today you can collide colors.
<masonf> gregwhitworth: interoperable styles - we have the same DOM and same styles. I'd prefer background colors, because that's how I build them, but I can easily do that. Just add a background-color. I'll always do that.
<masonf> gregwhitworth: Tim, there's a difference between popovers and inlines, right? On popovers there will be a background color.
<masonf> Tim: right.
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack chrishtr
<Zakim> chrishtr, you wanted to react to brecht_dr
<masonf> ack chrishtr
<gregwhitworth> chrishtr: the most important thing is compatible styles that are easy to override and the second most is consistency with how elements work with the web
<gregwhitworth> chrishtr: second thing we can stroll poll
<masonf> Straw poll: 1) transparent background colors, 2) system colors
<gregwhitworth> ack davidleininger
<gregwhitworth> davidleininger: I want to be clear on appearance: base is that currentcolor comes into inputs as that doesn't currently work
<gregwhitworth> davidleininger: there are so many other little things that can impact this
<gregwhitworth> fantasai: we inherit from the parent, not from the body
<gregwhitworth> davidleininger: if it inherits from the parent and it inherits from the parent and it's a mismatch how do we handle that?
<dbaron> Is the straw poll just about the in-page part of the controls?
<fantasai> Should be, yes
<gregwhitworth> ntim: the text color inherits from the parent and the background of parent inherits as well so as long as the contrast is correct then this should work
<gregwhitworth> davidleininger: I can see this not having a reasonable pair and you're putting a background on a fieldset but it's not meant to be transparent, I can see it causing potential issues and maybe that's something we're ok with
<gregwhitworth> ntim: you'll want to set the text color on the fieldset if you're setting the background
<masonf> Straw poll: for *in-page controls* (not popover pickers): 1) transparent background colors, 2) system colors
<argyle> "base" could learn alot from the wildly popular "headless ui" libs, since that sounds like what this group is hoping "base" can be?
<argyle> https://nerdy.dev/headless-boneless-and-skinless-ui#headless-ui
<gregwhitworth> davidleininger: I'm not going to lose sleep over it
<fantasai> masonf, you forgot about inheriting the color :)
<gregwhitworth> anne: so they would not set the color property
<gregwhitworth> davidleininger: people build things in terrible ways all the time
<gregwhitworth> davidleininger: I'm going to throw this standard element inside of this element and it's going to house the form but the form is white and they use a div that is grey background and they apply appearance: base and it's a grey one now there is no background
<gregwhitworth> davidleininger: the have had a white background for so long that it could mess with things
<gregwhitworth> anne: they could not use the H3 in that context
<chrishtr> q?
<masonf> fantasai, yeah. Colors *are* inherited, they're just overridden in the current stylesheet. Right?
<gregwhitworth> anne: if you set display: none on your root should we disable that?
<gregwhitworth> davidleininger: we're not making that the default
<gregwhitworth> masonf: the label on the element on the would not have contrast
<gregwhitworth> ack dandclark
<gregwhitworth> dandclark: I'll agree with gregwhitworth and chrishtr is the priority and either of these options are viable for that
<masonf> +1 to fantasai's version of the poll. Just to be completely transparent. ;-)
<gregwhitworth> dandclark: apologies if I missed this and we need to have multiple colors such as range, seems like we're locked into one foreground color?
<gregwhitworth> dandclark: how would you expect that to work
<gregwhitworth> ntim: we could use mixes of current color with lumances and have one color, etc
<argyle> #2
<masonf> 1+
<dbaron> POLL: for *in-page* part of the control (not popover pickers): 1) inherit 'color', transparent 'background' or 2) use system colors
<masonf> 1
<chrishtr> 1
<ntim> 1
<fantasai> 1
<gregwhitworth> abstain
<astearns> abstain
<jarhar> 1
<dbaron> 1
<davidleininger> 2
<dandclark> 1
<emilio> 2
<brecht_dr> 2
<ntim> RESOLVED: Use currentColor for borders, inherit the color, transparent background color (for in-page controls). Use system colors for pickers.
<ntim> We force system colors in forced colors mode, figure out what would be the best mechanism.