Live data from Hacker News

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

bram.us

51–60 of 74 posts

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

#51
post #21

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 visu…

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

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

#52
post #21

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 visu…

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

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

#53

"Here is an up-to-date list of browser support for the CSS :has() selector:" I think this text is wrong. https://caniuse.com/?search=light-dark does not have an entry for this yet.

( Hi, author of the post here) Thanks for catching this. I’ve updated the post to fix this copy-paste error.

CanIUse has no entry for it, as this feature is brand new. The PR add the data (https://github.com/mdn/browser-compat-data/pull/20935) is still pending.

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

#54

This is so wrong on so many levels. What about Light-Grey-Dark()?

(Hi, author of the post here) `grey` is no accepted value for `color-scheme`, so that would make no sense.

Note that `light-dark()` is not the end station here, it’s a step towards a future function that (1) would be able to respond to any value for `color-scheme` and (2) can return any type of value.

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

#55

How does this deal with the ternary of light/dark/high-contrast that a lot of sites are now using? I wish they would just enable features that are already in the browser that they've not put live, like grid-template-rows: masonry. All three major engines have the damned thing in there but it's not in release branch.

Masonry isn’t ready to be shipped as there are still quite a few open spec issues [^1] that need to be resolved first.

[^1]: https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+is%3...

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

#56

Oof. Unless I’m missing something, this is a convenience that doesn’t enable anything new and uses syntax/terms that don’t naturally generalize for future applications. It just embeds one recent trend in very specific, very rigid terms. This is how standards get bloated.

(Hi, author of the post/article here)

Yes, `light-dark()` is very specific in what it can do … but it’s not the end goal. The end goal is to have a generic function – something like `schemed-value()` – that can respond to a plentitude of `color-scheme` values and return more than just `` values.

Reality is, though, that browsers don’t have support for custom `color-scheme` values (it’s explicitly forbidden in the spec, for now) [^1] and that CSS parsers need to know ahead of time what they are about to parse [^2].

By narrowing things down in feature scope, you can use this convenience method now, instead of needing to wait a few months/years until the rest is figured out.

Once `schemed-value()` becomes a thing, `light-dark()` can become syntactic sugar for it:

``` light-dark(, ); = schemed-value(light , dark ); ```

[^1]: https://drafts.csswg.org/css-color-adjust/#color-scheme-prop... [^2]: https://www.w3.org/TR/css-syntax-3/#parse-grammar

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

#57
post #21

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 visu…

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

I hope this addresses your concern. If not, feel free to let me (or the CSS WG for that matter) know.

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

#59

Remember when UIs were customisable to the point that you could choose any colour for all the elements? Now it's "you can have any colour you want, as long as it's light or dark", and all of a sudden "dark mode" is heralded as something revolutionary and new. CSS3 even deprecated the "system colors" feature that was meant to allow the same degree of UI customisation we had before for websites too. It's nothing but a…

Heh, I was thinking about this recently, but from a slightly different angle: most browsers don’t feel like user agents any more. https://untested.sonnet.io/The+modern+Web+has+lost+the+User+... Personally, I don’t mind the light-dark function although I don’t see much utility in it, since I use variables for this sort of thing.

Set your browser to always use reader mode, on desktop and mobile. It solves all the problems of modern web browsing. Web sites do not deserve to use any of their own CSS or layout by default.

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

#60
post #33

Earlier quoted context omitted.

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.

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.

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

Post reply on HN