4 ms·

I've done a LOT of dark mode work, to the point where I'd consider myself an expert here[1]. I'm not a fan of this. This solves one tiny aspect of the larger p

by jjcm 3y ago

I've done a LOT of dark mode work, to the point where I'd consider myself an expert here[1]. I'm not a fan of this. This solves one tiny aspect of the larger problem in a non-scalable way that will inevitably lead to bloat and inflexibility. It's a really a naive approach that hasn't taken into account design at scale, nor the future of where design is heading. Typically when doing theming, you have two axes - a visual mode axis (i.e. light/dark/high contrast/colorblind modes/etc) and a theme axis (i.e. docs/sheets/slides, each with a different brand color). While this does solve an aspect of the visual mode axis, as soon as you add either a new theme or a visual accessibility mode, you'll be forced to refactor. I see that as codesmell. I also don't think this helps drive a better future of theming support. If we think about the future of theming, what we see today is a convergence of design patterns. Nearly everyone is doing theming at scale in at least roughly the same way (a semantic token layer that points to different primitive colors depending on the theme), and the differences between implementations continues to diminish over time. The convergence of patterns is a good thing - it means more code can be shared. If you wanted to actually solve theming, what you should work for is not a constrained helper function like light-dark(), but instead a shared token schema. Today nearly every company has their own token schema and different ways of naming things in the semantic token layer. If we had a shard language here, not only would it be trivial to add light/dark theming (just redefine a few variables that are already provided for you), code could be shared between sites and inherit the theming/branding. [1] Most recently leading Figma's dark mode stream, and currently leading their variables feature work to enable others to easily do light/dark/etc. I've consulted with 50+ enterprise tier companies on their theming. Also contributed to the W3C design token proposal for theme/mode support: https://github.com/design-tokens/community-group/issues/210 https://github.com/design-tokens/community-group/issues/210. Previously worked on Jira's dark mode + a few other projects.

jjcm 3y ago
FWIW, I added a comment here around a simple but more flexible proposal, that allows for easy light/dark theming via this approach, but would at least scale (and would allow for color-scheme's custom identifier support to be useful): https://github.com/w3c/csswg-drafts/issues/7561#issuecomment-1754069460 https://github.com/w3c/csswg-drafts/issues/7561#issuecomment...
qingcharles 3y ago
That link goes deep. I agree about the tokenizing. I hate that we've picked off all the easy work on web design and now we're into problems we never even imagined 10 years ago, e.g. multiple visual modes, differing color spaces etc. This stuff is getting really, really hard to do well and do it right -- it is very easy to make things worse for a lot of users, rather than better.
stevage 3y ago
Remember that the projects you work on are not typical of most CSS usage in the world. For small projects that never need to "scale", this looks handy.
- hyperhopper 3y ago
  Even if you never need to scale, Having light/dark & high contrast is just having basic features and complying to the law. If your site has 50 users it should have these, and this new light/dark switch is still inappropriate for even this basic use case.
  - extra88 3y ago
    What law? The U.S.'s Section 508 and other laws and regulations based on WCAG, don't require that sites honor `prefers-color-scheme` or to work correctly when `forced-colors` is active. Nevertheless, it's a good idea to do so (though if a site honors `prefers-color-scheme` it should also have a setting so the user can choose to have that site not match their system's color scheme setting).
- jjcm 3y ago
  Very true! Nonetheless this approach would also break compatibility with `color-scheme`'s custom identifiers, which is just bad in general for CSS even for these small projects. The alternative proposal I put together here would allow this to scale and still provide a helper function for small projects to use: https://github.com/w3c/csswg-drafts/issues/7561#issuecomment-1754069460 https://github.com/w3c/csswg-drafts/issues/7561#issuecomment...
  - wldcordeiro 3y ago
    I appreciate that you not only have a nuanced critique but an alternative proposal as well.
  - stevage 3y ago
    I do like your alternative proposal. For the viewers at home: :root { color-scheme: light dark high-contrast; } body { background: scheme(light #eee, dark #333, high-contrast #fff); }
beezlewax 3y ago
Jira has a dark mode??
- adiabatty 3y ago
  Does now. It's pretty nice.
the_gipsy 3y ago
> shared token schema Could you explain or give an example of what this is?
- c-hendricks 3y ago
  theme-ui (https://theme-ui.com/getting-started https://theme-ui.com/getting-started), mui's `Theme` (https://mui.com/material-ui/customization/default-theme/ https://mui.com/material-ui/customization/default-theme/), bootstrap's variables Basically, when you think in purpose instead of colors.
grncdr 3y ago
> If you wanted to actually solve theming, what you should work for is not a constrained helper function like light-dark(), but instead a shared token schema. Today nearly every company has their own token schema and different ways of naming things in the semantic token layer. If we had a shard language here, not only would it be trivial to add light/dark theming (just redefine a few variables that are already provided for you), code could be shared between sites and inherit the theming/branding. Isn't that the idea behind https://open-props.style/ https://open-props.style/ (and https://theme-ui.com/ https://theme-ui.com/ in JS land)? I think it's a great idea, but hampered by the lack of adoption incentives for the very people that need to adopt it for it to become successful (design system/component library authors). It introduces constraints, but the promised interoperability is not really beneficial to the people who need to work within those constraints.
- c-hendricks 3y ago
  There's millions of downloads every week for mui and bootstrap. Anyone using them is using something like theme-ui.
padjo 3y ago
I agree this looks like it will be of questionable use at scale. That said I don’t see a shared token schema ever achieving much. Those sorts of efforts usually flounder because there’s little incentive for adoption until a critical mass is achieved
bramus 3y ago
(Hi, author of the post/article here) > This solves one tiny aspect of the larger problem in a non-scalable way that will inevitably lead to bloat and inflexibility. It's a really a naive approach that hasn't taken into account design at scale, nor the future of where design is heading. Note that `light-dark()` isn’t the end goal here. As discussed within the CSS WG, the end goal is to have a generic function `schemed-value()` to give you what you want. I realize this wasn’t included in the post, so I’ve added a new section to the post with this information: https://www.bram.us/2023/10/09/the-future-of-css-easy-light-dark-mode-color-switching-with-light-dark/#schemed-value https://www.bram.us/2023/10/09/the-future-of-css-easy-light-... I hope this addresses your concern. If not, feel free to let me (or the CSS WG for that matter) know.

by jjcm 3y ago

jjcm 3y ago

FWIW, I added a comment here around a simple but more flexible proposal, that allows for easy light/dark theming via this approach, but would at least scale (and would allow for color-scheme's custom identifier support to be useful): https://github.com/w3c/csswg-drafts/issues/7561#issuecomment-1754069460 https://github.com/w3c/csswg-drafts/issues/7561#issuecomment...

qingcharles 3y ago

That link goes deep. I agree about the tokenizing. I hate that we've picked off all the easy work on web design and now we're into problems we never even imagined 10 years ago, e.g. multiple visual modes, differing color spaces etc. This stuff is getting really, really hard to do well and do it right -- it is very easy to make things worse for a lot of users, rather than better.

stevage 3y ago

Remember that the projects you work on are not typical of most CSS usage in the world. For small projects that never need to "scale", this looks handy.

hyperhopper 3y ago
Even if you never need to scale, Having light/dark & high contrast is just having basic features and complying to the law. If your site has 50 users it should have these, and this new light/dark switch is still inappropriate for even this basic use case.
- extra88 3y ago
  What law? The U.S.'s Section 508 and other laws and regulations based on WCAG, don't require that sites honor `prefers-color-scheme` or to work correctly when `forced-colors` is active. Nevertheless, it's a good idea to do so (though if a site honors `prefers-color-scheme` it should also have a setting so the user can choose to have that site not match their system's color scheme setting).
jjcm 3y ago
Very true! Nonetheless this approach would also break compatibility with `color-scheme`'s custom identifiers, which is just bad in general for CSS even for these small projects. The alternative proposal I put together here would allow this to scale and still provide a helper function for small projects to use: https://github.com/w3c/csswg-drafts/issues/7561#issuecomment-1754069460 https://github.com/w3c/csswg-drafts/issues/7561#issuecomment...
- wldcordeiro 3y ago
  I appreciate that you not only have a nuanced critique but an alternative proposal as well.
- stevage 3y ago
  I do like your alternative proposal. For the viewers at home: :root { color-scheme: light dark high-contrast; } body { background: scheme(light #eee, dark #333, high-contrast #fff); }

beezlewax 3y ago

Jira has a dark mode??

adiabatty 3y ago
Does now. It's pretty nice.

the_gipsy 3y ago

> shared token schema Could you explain or give an example of what this is?

c-hendricks 3y ago
theme-ui (https://theme-ui.com/getting-started https://theme-ui.com/getting-started), mui's `Theme` (https://mui.com/material-ui/customization/default-theme/ https://mui.com/material-ui/customization/default-theme/), bootstrap's variables Basically, when you think in purpose instead of colors.

grncdr 3y ago

> If you wanted to actually solve theming, what you should work for is not a constrained helper function like light-dark(), but instead a shared token schema. Today nearly every company has their own token schema and different ways of naming things in the semantic token layer. If we had a shard language here, not only would it be trivial to add light/dark theming (just redefine a few variables that are already provided for you), code could be shared between sites and inherit the theming/branding. Isn't that the idea behind https://open-props.style/ https://open-props.style/ (and https://theme-ui.com/ https://theme-ui.com/ in JS land)? I think it's a great idea, but hampered by the lack of adoption incentives for the very people that need to adopt it for it to become successful (design system/component library authors). It introduces constraints, but the promised interoperability is not really beneficial to the people who need to work within those constraints.

c-hendricks 3y ago
There's millions of downloads every week for mui and bootstrap. Anyone using them is using something like theme-ui.

padjo 3y ago

I agree this looks like it will be of questionable use at scale. That said I don’t see a shared token schema ever achieving much. Those sorts of efforts usually flounder because there’s little incentive for adoption until a critical mass is achieved

bramus 3y ago

(Hi, author of the post/article here) > This solves one tiny aspect of the larger problem in a non-scalable way that will inevitably lead to bloat and inflexibility. It's a really a naive approach that hasn't taken into account design at scale, nor the future of where design is heading. Note that `light-dark()` isn’t the end goal here. As discussed within the CSS WG, the end goal is to have a generic function `schemed-value()` to give you what you want. I realize this wasn’t included in the post, so I’ve added a new section to the post with this information: https://www.bram.us/2023/10/09/the-future-of-css-easy-light-dark-mode-color-switching-with-light-dark/#schemed-value https://www.bram.us/2023/10/09/the-future-of-css-easy-light-... I hope this addresses your concern. If not, feel free to let me (or the CSS WG for that matter) know.