# Lea Verou's blog Web standards, Software Engineering, Product, Usability, and more This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Why Most Websites Should Avoid Persistent Dark Mode Toggles DevFeed: [Why Most Websites Should Avoid Persistent Dark Mode Toggles]() Original publisher: [Read original article]() Author: Lea Verou Published: 2026-09-02T00:00:00Z Content type: opinion Language: en Sources: [Lea Verou's blog]() Topics: [Dark Mode](), [CSS](), [Web Development](), [modern web development]() Tags: [blog](), [css](), [dark-mode](), [design](), [product-design](), [toggle](), [usability](), [ux](), [web]() ### AI overview The article argues that most websites should not use a persistent dark mode toggle. It retains a recommendation for a two-state control when such a control is required, switching between the system preference and its opposite rather than exposing separate light, dark, and system states. ### Source excerpt About a month ago, I wrote an article recommending that if you are going to have an always visible control for switching between light and dark mode, it should be a two-state toggle that alternates between system and whatever the current opposite of system is, not a tri-state one (system, light, dark). If you are forced to include such a control (say, someone is pointing a gun at you and shouting "code dammit! now!"), I stand by that recommendation: use two states, as described in the article. But the article explicitly doesn't answer the question "should you have one at all?". I was much more neutral on this at the time of writing. I am now firmly in the "no" camp. More on that below. The two-state toggle design proposed in my article can actually express all three data model states. What I didn't mention was that I had been meaning to write this article for years, but had been putting it off. What finally pushed me to write it 1 was that Bramus argued that some Modern Web Guidance I had written on this was incorrect. He assumed it was an oversight, that I simply hadn't thought of all the implications. On the contrary, my recommendation had been the result of some very careful consideration, combined with my HCI background. Surely, if I explained my reasoning well, he would see it! I tried to convince him through discussion (in person, as we were both in Berlin at the time) to no avail. My conclusion was that I must be doing a poor job explaining my reasoning, and that a blog post was in order to explain it properly. Surely, after that he would be convinced! And thus, one of my most successful blog posts was born. Reactions This article really made the rounds. It was shared by hundreds of folks, including people I really respect, such as: ShadCN Paul Kinlan Kevin Powell John-David Dalton Tab Atkins-Bittner Cory LaViska Ahmad Shadeed Josh Tumath and many others. A lot more who hearted it. Some of the quotes really made me blush โ˜บ. Here is a small selection: I wasn' ## Dark mode toggles: two states are enough DevFeed: [Dark mode toggles: two states are enough]() Original publisher: [Read original article]() Author: Lea Verou Published: 2026-08-06T00:00:00Z Content type: opinion Language: en Sources: [Lea Verou's blog]() Topics: [Dark Mode](), [User experience (UX)](), [Users](), [ui](), [Website]() Tags: [blog](), [dark-mode](), [product-design](), [ui](), [usability](), [users](), [ux](), [website]() ### AI overview The article argues that a two-state dark mode toggle is usually preferable to a three-state Light, Dark, and System control for websites. It explains that users typically seek a theme toggle when the current appearance needs to change, not to express a persistent preference, and that tri-state controls add unnecessary complexity and UX friction. ### Source excerpt A good two-state toggle can actually express all three data model states. Until recently, if you looked at most websites with a theme toggle1, you'd find three options: Light, Dark, and System. Examples of tri-state dark mode toggles. In (LTR) reading direction: Tailwind, Red Hat Design System, Ant Design, Web Awesome, Excalidraw, Taiga, Astro, Hero UI. Thankfully, these days the trend has shifted towards a simpler two-state toggle, but tri-state ones are still incredibly common. Examples of two-state dark mode toggles. In (LTR) reading direction: Vitepress, Material Design, Adobe Spectrum, Radix, ShadCN. The rationale sounds plausible: "System" is a different intent than "Light" or "Dark"! One is a policy (whatever my OS says, do that) The other is a value (dark, forever, I don't care what my OS says.) Surely, users should be able to express that intent! Except, real users don't generally seek out dark mode toggles to express intent for things to stay as they are, they seek them out when things need to change. Think of the user goal when browsing a website (as opposed to a separate Settings page, where three states are fine). E.g. on a documentation site, they may be there to look something up. On a landing page, they may be trying to evaluate whether the product is suitable for their needs. On a media site, they may be there to read the news. On a graphics app, they want to draw something. One thing is for certain: tweaking the theme is not their primary goal 2. To get in the mindset of tweaking the theme, something needs to be off. When things look right, users just move on with their actual goal instead of thinking about the theme. The tri-state control is solving a largely imaginary user goal that is extremely rare among real users, and does not justify the additional complication and UX friction of a three-state toggle. Worse, it forces the user to decide between choices that produce no visible difference, breaking the principle of feedback. Yes, tri-state tog ## In defense of polyfills DevFeed: [In defense of polyfills]() Original publisher: [Read original article]() Author: Lea Verou Published: 2026-07-13T00:00:00Z Content type: opinion Language: en Sources: [Lea Verou's blog]() Topics: [Web platform](), [web-standards](), [Document Object Model (DOM)]() Tags: [blog](), [library](), [polyfills](), [web-platform](), [web-standards](), [whatwg]() ### AI overview An opinion defending polyfills argues that their benefits for the Web generally outweigh rare cases where they can constrain the design space of native APIs. It discusses the tension between polyfillability and preserving flexibility in Web platform standards. ### Source excerpt If you're a web developer, you may find the title baffling. "Polyfills need defending? Who's against them?!" you might ask. Two weeks ago, I'd be in the same boat. Polyfills and I go way back. I dug up a JSConf EU talk of mine from 2011 on exactly this topic. Trying not to think about how young I look here ๐Ÿ˜… One of the few opinions I have held strongly over the years is that polyfills are a net positive for the Web, and the good outweighs the rare failure cases where polyfills became too popular, too soon, and restricted the design space for the native API. As with most things in life, it's all about the cost-benefit. We don't stop flying planes because crashes happen. We do a post-mortem and figure out how we can prevent the same accident from happening again. And crucially, the point of a post-mortem is to find the root cause -- not to ground the entire fleet. Don't get me wrong, concerns about polyfills are well-intentioned. They come from implementors and standards folks who want to preserve the design flexibility to build the best API surface possible -- a goal I share deeply. Being both a spec editor and a library author, striking that balance is something I navigate all the time. Still, I was under the impression that seeing polyfills as a net positive was the consensus view of the web standards community as a whole. That while we may not have consensus on the specific tradeoffs or solutions, we see polyfilling as a good thing and we generally do want web platform features to be polyfillable. So, you can imagine my surprise when in a recent WHATWG meeting where I presented a proposal for extending mutation observers to observe shadow root attachment, Anne van Kesteren expressed the view that polyfilling is harmful. It's important to note that Anne is not some rando. He is the main active editor of most WHATWG specs (HTML, DOM, Fetch, import maps, etc.), a WebKit engineer at Apple, and has tremendous overall influence on the direction of the Web platform. I had ## External import maps, today! DevFeed: [External import maps, today!]() Original publisher: [Read original article]() Author: Lea Verou Published: 2026-03-02T00:00:00Z Content type: article Language: en Sources: [Lea Verou's blog]() Topics: [import](), [Document Object Model (DOM)](), [Script](), [Web Development](), [Web](), [browsers](), [Chrome](), [Firefox](), [Single-page application (SPA)]() Tags: [async](), [blog](), [browser](), [browser-support](), [chrome](), [defer](), [firefox](), [html](), [implementation](), [import](), [js](), [modules](), [script](), [tip](), [web-architecture](), [web-standards]() ### AI overview This article explains how to emulate external import maps today by dynamically injecting an import map with DOM methods from a classic blocking script. It describes the required script ordering, compatibility considerations, and browser support, including Chrome, Safari, and Firefox. ### Source excerpt A few weeks ago, I posted Web dependencies are broken. Can we fix them?. Today's post is a little less gloomy: Turns out that the major limitation that would allow centralized set-it-and-forget-it import map management can be lifted today, with excellent browser support! The core idea is that you can use DOM methods to inject an import map dynamically, by literally creating an to your template for every page. But you don't need a templating system: even if you're rawdogging HTML (e.g. for a simple SPA), it's no big deal to just include a in there manually. This is not even new: when the injector is a classic (non-module) script placed before any modules are fetched, it works in every import map implementation, all the way back to Chrome 89, Safari 16.4+, and Firefox 108+! Turns out, JSPM made the same discovery: JSPM v4 uses the same technique. It is unclear why it took all of us so long to discover it but I'm glad we got there. How does it work? Basic import map injector script First, while there is some progress around making import maps more resilient, your best bet for maximum compatibility is for the injector script to be a good ol' blocking