Bug: [Select Component] options text color does not switch properly in dark themes

[brambow]

Describe the bug
The Select component options do not show up properly on Windows and Ubuntu when using a theme with dark backgrounds and light fontColors.

To Reproduce
Steps to reproduce the behavior:

1. Go to the Select components doc page using Windows or Ubuntu OS
2. Switch to Dark Mode
3. Expand the Select dropdown from the example
4. See error

Expected behavior
The select options should be visible.

Screenshots

[flo-sch]

Is that fixable by theme-ui in a "white-label" way though? 🤔

The <Select /> component apply a color: inherit rule which seems to work fine on Mac OS (both light and dark color modes)

Of course we can always override the default browser behavior, but I am wondering whether this should rather be a theme / color-mode responsibility (or even a system issue here?)

[brambow]

I'd think most people expect components like Select to be functional out of the box across all major OS, without the need to "fix" it in each app we build. Can you link to another component package with a Select component that does not do so? I would definitely not use MacOS as the the standard - even though a lot of devs work on it, very few application users do.

[flo-sch]

I would definitely not use MacOS as the the standard

I'm with you here, my question is if this issue is indeed caused by theme-ui or by the native style applied on Windows/Linux, which theme-ui may then need to support by itself 🤷

Currently the Select component applies:

background-color: inherit;
color: inherit;

Default style for HTML <select /> is background-color: white (even on dark mode AFAIK), which here is overriden by theme-ui's <Select /> style.

One resolution could be to also override the color (like for instance Bumbag's Select does), potentially on dark-mode only, to streamline the style accross browsers (would that work everywhere 🤔)

But since theme-ui is intended to be white-label, without default theme, thus not aware of the application theme and the colors you may or may not provide at implementation, which color should we use in that case...? Hence my question.

I'd think most people expect components like Select to be functional out of the box across all major OS

Arguably, theme-ui allows you to style it in your application OOTB, with the theme and/or color modes support you wish to provide. For instance the following should probably fix the color issue on all systems?
https://codesandbox.io/s/theme-ui-select-color-modes-pby5i

Do you know another UI library with a Select component that works as you expect in all system and color modes?
There may be a nice white-label way I do not know about 😉

[brambow]

One resolution could be to also override the color (like for instance Bumbag's Select does), potentially on dark-mode only, to streamline the style accross browsers (would that work everywhere 🤔)

Actually Bumbag suffers this exact same issue.

Arguably, theme-ui allows you to style it in your application OOTB, with the theme and/or color modes support you wish to provide. For instance the following should probably fix the color issue on all systems?
https://codesandbox.io/s/theme-ui-select-color-modes-pby5i

Requires the use of colorModes in the theme. None of the applications where I've had users complain about this make use of this theme feature.

I'd say it's pretty unreasonable to expect devs to fix this at the application level every time. I'd use the fact that this very library's docs page have failed to do so as evidence that devs won't remember to do that and probably aren't checking.

Could we not do something to check that the Select's color and backgroundColor are not equal?

But since theme-ui is intended to be white-label, without default theme, thus not aware of the application theme and the colors you may or may not provide at implementation, which color should we use in that case...? Hence my question.

Black text on white background.

Do you know another UI library with a Select component that works as you expect in all system and color modes?

Material UI, but it might not be a true Select.

[hasparus]

I think both Theme UI and Bumbag need a fix for it.

We don't even have to go "full custom styling"s way like react-spectrum — https://react-spectrum.adobe.com/react-spectrum/Picker.html. A solution like presented in the @flo-sch's sandbox would be enough.

What do you guys think about adding the following to Select's styles:

backgroundColor: theme => {
  const background = get(theme, 'colors.background')
  return typeof background === 'string' ? background : "inherit"
}

This way, if colors.background is a string, or an object with __default value, we'd use its value, otherwise default to "inherit".

---

Edit: Actually, scratch that. "inherit" doesn't work at all (not on my machine at least). Let's just write "background" there.

[flo-sch]

get(theme, 'colors.background') sounds like a good idea (never used that function directly) can it reference a key under color modes as well (assuming it exists and color mode is set etc.?)

I see one potential issue with hardcoding "background": if the theme does not set it, it would be forwarded as such: background-color: background which seems to cause an "interesting" highly non-standard side-effect in some versions of Chrome (current latest on both Mac OS & Windows) 🤷‍♂️
(Unless this comes from a browser extension or something? 🤔)

Unless those keys are always supposed to be set per specifications and we can ignore that very edgy scenario? :D

Could we not do something to check that the Select's color and backgroundColor are not equal?

That would be optimal, but not sure how to achieve that within the APIs of theme-ui

[hasparus]

I see one potential issue with hardcoding "background": if the theme does not set it, it would be forwarded as such: background-color: background which seems to cause an "interesting" highly non-standard side-effect in some versions of Chrome (current latest on both Mac OS & Windows)

From my perspective, themes without a background color are "illegal" for users of Theme UI components, but yeah, we could do get(theme, colors.background, null) for example to avoid that purple glitch.

[lachlanjc]

I have not tested this/I'm not sure if these are related, but isn't this more an issue with color-scheme/telling the browser we support dark mode? See the second half of https://web.dev/color-scheme/

[hasparus]

Hey @brambow, @flo-sch. Are you possibly interested in creating a PR for this problem or should I handle it?

(backgroundColor: theme => get(theme, colors.background, null) in Select's styles instead of inherit should work)

[brambow]

I will try to make a PR for this over the weekend

[brambow]

Are there some guidelines for running the development server? I'd like to preview the docs page in development against the changes I've made to Select. I'm not quite clear on how to do that though.

[lachlanjc]

Are there some guidelines for running the development server? I'd like to preview the docs page in development against the changes I've made to Select. I'm not quite clear on how to do that though.

Check out this doc: https://github.com/system-ui/theme-ui/blob/develop/CONTRIBUTING.md you should be able to yarn then yarn workspace docs start!

[brambow]

Thanks! Those contributing guidelines read like the command should be yarn start docs. That's where I was getting tripped up.

Should running the docs in development mode actively reflect my changes? Before working on the change for this issue, I tried some basic changes to packages/components/src/Select.js, like hardcoding the background color to light green. I saved those changes and then started the docs development server, but I'm not seeing my css change show up in the docs. Is that the right way to preview changes to components, or are the docs pointing at a built version of the components package?

Would there be interest for adding Storybook to the components package? I have a configuration and custom ThemeUI addon for it that works with the latest ThemeUI version, which I use for this project: https://cartolab-gis.github.io/elements/. It's a pretty great tool for developing and providing a playground for component libraries.

[lachlanjc]

Ah, good flag on the command! PRs to improve that doc would be great.

Should running the docs in development mode actively reflect my changes?

You'll need to build or watch whatever packages you're editing for the docs to reflect them, but because of yarn workspaces that should automatically link. If you want to use a different demo site locally, like a storybook, run yarn link in the components directory, then in your website, yarn link @theme-ui/components. That will use your local copy instead of downloading it from npm.

[hasparus]

Should running the docs in development mode actively reflect my changes? Before working on the change for this issue, I tried some basic changes to packages/components/src/Select.js, like hardcoding the background color to light green. I saved those changes and then started the docs development server, but I'm not seeing my css change show up in the docs.

Hey guys that "preconstruct dev" in postinstall should set you up so you don't need to rebuild.

Peek.2021-05-03.23-46.mp4

I do have to admit that contributing docs might be a bit outdated, but uhh... for my defense I expected that "postinstall" to run automatically on your machines.

This is the expected output:

⇝  yarn postinstall
yarn run v1.22.5
$ preconstruct dev && patch-package
🎁 info project is valid!
🎁 success created links!
patch-package 6.4.7
Applying patches...
@endemolshinegroup/[email protected] ✔
Done in 1.46s.

Take a look at dist dirs if you're interested to see what happens there. TLDR Preconstruct is wicked smart and no watch steps burning my old laptop are needed anymore.

[lachlanjc]

Oh amazing! I haven't really used the Preconstruct setup I guess. Is there anything we should update on CONTRIBUTING?

[hasparus]

Is there anything we should update on CONTRIBUTING?

#1715