kind of sad that the CSS specification wound up with this clunky `light-dark(white,black)` thing instead of literally anything more extensible like, `themed(dark(black), light(white), retro(purple))`.
Then you'd be able to have a cool theme dropdown like sites used to have, fully CSS-driven with essentially no JS required, in a compatible and modern way.
I thought this was going to be about how people prefer different levels of blackness for the background in dark mode. I've heard people say that pure black is more battery efficient for OLED displays (but don't know if this is true), and I know some folks prefer a less-inky grey.
I was wondering how there could be six levels though; I'd think 3 or 4 would be the most anyone could notice or care about.
I do wish there was more conversation around the levels of blackness for dark modes. Black screen and white text is physically painful for me. I usually have to resort to reader mode, or open up dev tools and change colors myself, to make a page like this readable for me.
I appreciate how hard it can be to make a good dark mode; I've spent months building a custom dark theme I term "mid-contrast". It's still WCAG compliant, but easy on my eyes, and I've stuck with the (maybe silly?) requirement of 16 colors only, like Solarized.
It is significantly more efficient for oled displays, as off oleds don't use power. It also causes burn in on a smaller part of the display which is usually good (but this could end up being a disadvantage over time as the burn in contrast is higher).
It's also more efficient for led matrix backlights.
Edit: sorry, realized this is misleading: my testing was with light vs dark, not something like dark grey vs 00 black
The more universal solution would be to standardize Reader Mode compatibility, and for browsers to let users configure how they want Reader Mode to look.
In other words, instead of an n x m solution where every web site has to cater to each different user preference, there should be a simplified content view that every web site only has to support in a singular way, and that allows browsers to cater to the various user preferences.
This likely would have happened already if it weren't for Google's hostility to Reader Mode. It's hilarious to see the Reader Mode that they offer, where it's a resizable 2-column view, to ensure that ads are loaded and kept in sight. We get it, Google: you don't want to endanger your ad revenue.
I feel like we could go beyond that, especially for more app-like experiences. Maybe we want themes that do things like "add specific trim to make editable fields more identifiable." or adding "high contrast" versions of the themes for low-quality screens or low-vision users.
There's no reason a webpage shouldn't be as themable as, say, a GTK or Qt based desktop application.
We should be trying to snatch back styling power from the designers and putting it back on the user-agent's side. Let the page look brutalist until the user has chosen an appropriate theme for their needs rather than railroading them into what someone in Marketing decided looked good.
for OLEDs, I tend to prefer pure black because it doesn't burn-in. Since they have a limited lifetime, any "on" time is costing me usage in the long-long-long run and I'd rather have my monitor last 5+ years than ... 2 or 3.
>any "on" time is costing me usage in the long-long-long run and I'd rather have my monitor last 5+ years than ... 2 or 3.
Going from dark gray to pure black isn't going to halve your monitor expectancy, if it makes a difference at all. Due to how human perception works something that's merely dark gray is actually orders of magnitude brighter than pure white, or even 50% gray. Therefore most of your burn-in is going to be driven by bright content like photos or white text, not whether you're using 5% gray vs pure black.
how your users' browsers choose to render `about:blank` while waiting on your page to be delivered is outside of both your control and concern
on Gnome i've got system-wide dark mode turned on and idk, my Firefox is dark gray until it gets any content. so users have the power and should exercise it to tailor their experience as they wish
> Dedicated files make sense if you do a lot of customization. The browser may ignore any CSS file that does not match the query, so there’ll be one less thing to download.
That’s not how it actually works: in practice, browsers download them all. They may prioritise them differently, but they’ll still download them all in the end.
kind of sad that the CSS specification wound up with this clunky `light-dark(white,black)` thing instead of literally anything more extensible like, `themed(dark(black), light(white), retro(purple))`.
Then you'd be able to have a cool theme dropdown like sites used to have, fully CSS-driven with essentially no JS required, in a compatible and modern way.
I thought this was going to be about how people prefer different levels of blackness for the background in dark mode. I've heard people say that pure black is more battery efficient for OLED displays (but don't know if this is true), and I know some folks prefer a less-inky grey.
I was wondering how there could be six levels though; I'd think 3 or 4 would be the most anyone could notice or care about.
I do wish there was more conversation around the levels of blackness for dark modes. Black screen and white text is physically painful for me. I usually have to resort to reader mode, or open up dev tools and change colors myself, to make a page like this readable for me.
I appreciate how hard it can be to make a good dark mode; I've spent months building a custom dark theme I term "mid-contrast". It's still WCAG compliant, but easy on my eyes, and I've stuck with the (maybe silly?) requirement of 16 colors only, like Solarized.
It is significantly more efficient for oled displays, as off oleds don't use power. It also causes burn in on a smaller part of the display which is usually good (but this could end up being a disadvantage over time as the burn in contrast is higher).
It's also more efficient for led matrix backlights.
Edit: sorry, realized this is misleading: my testing was with light vs dark, not something like dark grey vs 00 black
The more universal solution would be to standardize Reader Mode compatibility, and for browsers to let users configure how they want Reader Mode to look.
In other words, instead of an n x m solution where every web site has to cater to each different user preference, there should be a simplified content view that every web site only has to support in a singular way, and that allows browsers to cater to the various user preferences.
Shh, don't tell web designers about reader mode! They'll try to break it!
This likely would have happened already if it weren't for Google's hostility to Reader Mode. It's hilarious to see the Reader Mode that they offer, where it's a resizable 2-column view, to ensure that ads are loaded and kept in sight. We get it, Google: you don't want to endanger your ad revenue.
It's just n x 2 for light and dark themes.
I feel like we could go beyond that, especially for more app-like experiences. Maybe we want themes that do things like "add specific trim to make editable fields more identifiable." or adding "high contrast" versions of the themes for low-quality screens or low-vision users.
There's no reason a webpage shouldn't be as themable as, say, a GTK or Qt based desktop application.
We should be trying to snatch back styling power from the designers and putting it back on the user-agent's side. Let the page look brutalist until the user has chosen an appropriate theme for their needs rather than railroading them into what someone in Marketing decided looked good.
>I've heard people say that pure black is more battery efficient for OLED displays (but don't know if this is true)
No.
https://www.xda-developers.com/amoled-black-vs-gray-dark-mod...
Did you even read before pasting? Yes technically it is, which would indeed be in line with "levels of dark mode".
Grayish dark themes are underrated
for OLEDs, I tend to prefer pure black because it doesn't burn-in. Since they have a limited lifetime, any "on" time is costing me usage in the long-long-long run and I'd rather have my monitor last 5+ years than ... 2 or 3.
>any "on" time is costing me usage in the long-long-long run and I'd rather have my monitor last 5+ years than ... 2 or 3.
Going from dark gray to pure black isn't going to halve your monitor expectancy, if it makes a difference at all. Due to how human perception works something that's merely dark gray is actually orders of magnitude brighter than pure white, or even 50% gray. Therefore most of your burn-in is going to be driven by bright content like photos or white text, not whether you're using 5% gray vs pure black.
Is there still no way to prevent the flash bang while waiting for initial content from the server?
Use `background-color` in Firefox's `userContent.css`.
I love the idea of ending it for myself, but my users are still screwed?
how your users' browsers choose to render `about:blank` while waiting on your page to be delivered is outside of both your control and concern
on Gnome i've got system-wide dark mode turned on and idk, my Firefox is dark gray until it gets any content. so users have the power and should exercise it to tailor their experience as they wish
I don't know if I misunderstand the problem, but what about a style tag at the earliest part of the page indicating the background color to use?
That flashbang happens during the initial latency (DNS, RTT, any server slowness).
make dark mode the default, then it's a flash of dark in either case
send a blank black page then load from there?
Decrease screen brightness. Turn off dark mode. No flashbang. Bonus: Battery lasts longer.
Level 9 (or 0): Turn off the computer and go to sleep.
Glad OP got the tri-state toggle right!
> Dedicated files make sense if you do a lot of customization. The browser may ignore any CSS file that does not match the query, so there’ll be one less thing to download.
That’s not how it actually works: in practice, browsers download them all. They may prioritise them differently, but they’ll still download them all in the end.
Would've been cool if the levels came into effect while you scrolled down the page
Or were selectable by the reader at each appropriate position in the page.
It's 8 levels though?
Obligatory ? https://xkcd.com/3227/
so sad that he disabled this ability to propagate to other pages :(
it was the first time my eyes got comfortable reading his comics
Ah, the unofficial sequel to The Last Question.
2024