Also great for rich interactive experiences that use traditional server side rendering to a large degree, this would allow you to make something like the Spotify web application without the need for large client side heavy JavaScript to render things.
Note there is already UI component framework called Glimmer that is used by Ember.js: https://glimmerjs.com/. It's pretty much upstreamed into Ember itself these days, but the devs also have a big Rails background so I found the coincidence funny.
Storing the user preference in local storage opens up a whole can of worms. What if the user has multiple tabs/windows open? Now you should probably be using the 'storage' event to synchronize the state (which is not done in this article). Otherwise, prepare to be blasted with a sea of white when switching tabs.
What if the user toggles their preference on a system level? Should this then override the locally stored value? Should it be cleared? Or is the stored preference persisted over the system preference at all times, leaving the user unable to reset the value to restore the behavior of following system preferences first.
Additionally, you will now have to add JavaScript in a critical page load path to add classes to avoid a flash of the wrong color. As well as critical CSS to ensure the most basic colors are applied early on while the rest of your stylesheet loads in.
My take on this is, don't even try to add a dark mode toggle to the site itself, always rely on CSS and never JS. This is the responsibility of the browser, you can even customize the appearance in your browser settings separately of the operating system. It will load user agent styles with dark mode if the 'color-scheme' meta is set correctly, so you don't have to even do the critical styles to avoid flashes.
I would really like to see Firefox, Chrome, etc. add a dark mode toggle in the navigation bar that could simply be used to toggle the 'prefers-color-scheme' value on sites that have the 'color-scheme' meta set up correctly, so we don't have to constantly implement this feature over and over again on every site (usually done wrong).
Absolutely agree. It's the browser's job to respect and maintain my OS-level dark mode. Nothing else will ever be able to stop the dreaded full-screen-white-flash-while-loading. On OLEDS and AR/VR this should bear "epilepsy warning" as these flashes of white screen are pure torture.
> But what if users want to override their system preference for a site? Just because a user prefers dark mode for their OS doesn’t always mean they prefer it on a website. That’s why providing a way to manually override dark mode, despite the system settings, is a good idea.
And I agree. You want to follow the OS, but be able to override per-site.
I like dark mode at night but it strains my eyes to read longform text in it. So I want news sites and Wikipedia only to stay in light mode, and I turn my brightness way down while I'm reading them.
Yes, sure, I agree, but even then, what is the harm of a BLACK page flashing for a moment while the site is loading? None. In cinema, for example, fade-to-black is ordinary but purely white scenes are extremely rare.
Some things are more important than free market capitalism, and making sure you’re not dependent on hostile countries for key technology is one of them.
Once, if you're just talking about nuclear reactors. The reactor vessel didn't explode at Fukushima, just the outer building due to accumulated hydrogen. TMI didn't explode at all, the fuel melted but didn't breach containment.
> that's just not something most new developers understand.
That is just false if you ask me. Eventually you reach the limits of the API defined by a framework and users will have to reach out to HTML and CSS. And now is there not only a level of indirection, but also all of the existing documentation from the Web Platform cannot be applied.
I think there is validity for having a Python based system (instead of JS) that runs on the client to render standard HTML and CSS, but this goes beyond that and will just become an immense scope creep.
First Party Sets are legitimately terrifying to me, it gives a commercial party (Google) complete control over who is and isn't allowed to set cookies in a third-party context. It's Google using their absolutely dominating market share to force even more control.
There is PayPal if you go to their donate page, literally big American corporate. As a European (specifically Dutch), I have always HATED credit cards with a fiery passion, and dealing with big American corporations and their messy and buggy experiences on the web. In this regard many foreign systems such as iDeal, UPI, WeChat Pay and Alipay feel like they are straight from the future. But to each their own.
