[HN Gopher] The Future of CSS: Easy Light-Dark Mode Color Switch...
___________________________________________________________________
The Future of CSS: Easy Light-Dark Mode Color Switching with Light-
Dark()
Author : dcre
Score : 30 points
Date : 2023-10-09 22:08 UTC (52 minutes ago)
(HTM) web link (www.bram.us)
(TXT) w3m dump (www.bram.us)
| garganzol wrote:
| This is so wrong on so many levels. What about Light-Grey-Dark()?
| swatcoder wrote:
| 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.
| incrudible wrote:
| God forbid someone adds practical features for common use cases
| to our beautiful turing tarpit.
| imachine1980_ wrote:
| I agree with the previous comment that the current approach
| lacks flexibility in achieving high contrast. It might be
| beneficial to consider a more general and adaptable method
| that can accommodate different styles or even introduce
| primitives for different styles in the future
| DamonHD wrote:
| My entire automatic light/dark support is, very early in the
| HTML: <meta name=color-scheme content="light
| dark">
|
| then, in in-line CSS: @media (prefers-color-
| scheme:dark){body{background-
| color:#000;color:#eee}img{filter:brightness(.9)}}
|
| I'm not seeing this new thing as a huge win so far.
| qingcharles wrote:
| Interesting that you adjust the image brightness.
|
| I have everything set to dark mode, but I wouldn't want the
| images altered. Unless these are just navigational images on
| your site and you don't have any photos?
| garganzol wrote:
| Images with a full dynamic range look too bright in the dark
| mode. I set them to 0.9 as well on my resources, otherwise
| the eyes are bleeding deep in the night.
| RheingoldRiver wrote:
| How is this better than using CSS variables for light/dark mode?
| With CSS variables you have better isolation for consistency with
| your entire color scheme, and you can extend it to supporting
| multiple themes (e.g. light, dark, blue).
| qingcharles wrote:
| 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.
| userbinator wrote:
| 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 really sad regression in empowerment, the
| continuing trend of treating users like cattle.
| karaterobot wrote:
| I guess it's better than nothing, but this does not feel like a
| very CSS way of solving this problem. I think I'd rather write a
| separate block of styles for dark mode, the way you do for other
| media queries. Happy to hear why that's wrong though.
| incrudible wrote:
| It is not wrong, just annoying and error prone to write
| everything twice in two different places, but like you point
| out _that is the CSS way_.
| allan_s wrote:
| It's "only" colors ? So far from 100% of your css (especially
| if you use something like tailwind where css class for shape
| and color are clearly separated)
|
| Also I m not a css expert but can't you also simplify it by
| using css variables so that you can further reduce the scope
| of change by having only the css variables that change value
| ? Your --primary-color-500 etc.
___________________________________________________________________
(page generated 2023-10-09 23:00 UTC)