Waaaait - I recently implemented a simple dark mode for a simple page and thought
color-schemedeclares intent/support not influence how it is being rendered. I thought I still had to define dark coloring.I just checked and to my surprise the browser indeed serves different default/root coloring when dark color scheme is declared [as well]. :O This means I can simplify my CSS.
I must have been misled when skimming by “specifies compatibility” and “Component authors must use the prefers-color-scheme media feature to support the color schemes on the rest of the elements.” missing the browser behavior change description.
If you want to see this simple change in Nginx, they’re running a poll here: https://github.com/nginx/nginx/discussions/584
I agree with this decision. Don’t make error pages more complicated than they are.
It’s literally just one line of HTML though:
<meta name="color-scheme" content="light dark">Not complicated at all.
And some css, and accessibility issues. Dark mode isn’t actually great for everyone.
It doesn’t need any CSS since the Nginx error pages use the browser’s default styling. The meta tag just tells the browser to use its default light or dark mode styling depending on the user’s preference.
A standard behaviour on all sites that properly implement dark mode is that it adheres to the system-wide dark mode setting. If the user doesn’t want dark mode, they’d turn it off system-wide.
You didn’t actually check, did you?
Yes, I checked the pull request: https://github.com/nginx/nginx/pull/567/files and I’m also a web developer so I understand how it works.
🤡
Check what? They’re right.
accessibility issues
Respecting the user’s choice (whether to use dark mode or not) helps accessibility rather than hindering it.
They’re already more complicated than I want them to be so I’m passing on that
The team’s position for rejecting this seems reasonable, but then you look at the actual PR and you see that’s one extra line of html on the error pages and I can’t help but feel like it wasn’t a big deal to accept this.
I can understand the reasoning, but I would have weighed the significant benefit over the little “complexity”/content increase.
The color inversion is a significant effect. It doesn’t change anything for those that use their own error pages, but significantly improves the situation for people who land on these pages and are bothered by light mode.
/edit: Their PR close comment was super short (non-telling), but they later commented with some reasonable reasoning that better describes their point of view and considerations.
As if I needed another reason to avoid nginx.
Seems like a very simple, lightweight and elegant solution to keeping the engine up to modern standards. If they were serious about keeping complexity out they wouldn’t have such garbage site configuration.
Really, this minor issue you’ll never run into is a reason to avond nginx
It’s the little things that always add up. It’s not the lack of feature but their dismissal of it I guess.
Most server admins use custom 404 pages, so the default page isn’t that common in production.
Good to know. My experience with nginx is definitely on the light end. I much prefer traefik I guess coming from k3s world.
And yet everyone has stumbled into them a few times.
Some of my static sites are definitely not configured correctly and show the default error messages. A lot of sites have dynamic content though, and are often configured like:
try_files $uri $uri/ @backend;So any requests for files that don’t exist get routed to the backend, which usually shows its own error messages instead of Nginx’s.
