The Future of CSS: Easy Light-Dark Mode Color Switching with Light-Dark()

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  1. csswg-drafts

    CSS Working Group Editor Drafts

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

  2. SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
  3. community-group

    This is the official DTCG repository for the design tokens site and specification.

  4. theme-ui

    Build consistent, themeable React apps based on constraint-based design principles

    > 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/ (and 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.

  5. open-props

    CSS custom properties to help accelerate adaptive and consistent design.

    > 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/ (and 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.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • Design Token-Based UI Architecture

    2 projects | news.ycombinator.com | 18 Dec 2024
  • Design Systems: From Atomic Design to a Global Solution

    1 project | dev.to | 1 Mar 2024
  • Six new variables features launching today

    1 project | /r/FigmaDesign | 7 Dec 2023
  • My variables wishlist

    1 project | /r/FigmaDesign | 13 Jul 2023
  • Does anyone else find variables overwhelming?

    1 project | /r/FigmaDesign | 8 Jul 2023

Did you know that HTML is
the 9th most popular programming language
based on number of references?