There’s latency and extra network traffic, though with a static site those should be pretty low.
The UX might get a little weird in some ways — in the case of the site menu, the menu-open state becomes part of the history, so if you open the menu and click a link and go back, the menu’s still open. Then you go back again and it’s the same page but with the menu shut.
I expected the history to fill up as you described, but it seems the implementation avoids that by making the menu close button go back in history if possible. It does that with this HTML (shown unminified):
The code I quoted does work as intended in Safari on iPadOS 17: it prevents history from being filled when I repeatedly tap the menu button and the menu close button.
Perhaps rather than replying to me, you meant to comment on the article as a whole. I see that on iPadOS, the CSS transition animations don’t work. The page just blinks between states like any other page load.
I am really confused about this. Is this not the canonical way of making websites for 30 years? Is this about the fact that it has fancy animations?
Or is the author so young that the web is just set of html documents with URLs?
Having a separate HTML page for the open state of your navigation menu has never been the standard as far as I’m aware. The standard has been CSS/JavaScript for a decade or so, DHTML for the decade before that, and frames (always “open”) for the decade before that.
CSS/JavaScript for a decade or so, DHTML for the decade before that
Wasn’t DHTML just a fancy name for the practice of using JavaScript to change what is on a page? Is there a reason not to say “JavaScript for the decade before that”?
The Wikipedia page contrasts DHTML with Ajax, but even in the last decade, standard navigation menus wouldn’t use Ajax anyway.
Having a separate HTML page for the open state of your navigation menu has never been the standard as far as I’m aware.
I don’t know what this means. Asking without sarcasm: are you not aware that wesbsites predate JavaScript and were just collections of html documents without interactivity beyond following links and submitting forms?
The most primitive menus, still widely used, are just collections of links with consistent look and positioning across different pages you navigate by clicking on hyperlinks.
Those collections of links were not separate HTML pages, though—except in the case of frames, which I mentioned. Even if they were separate files included with things like Apache includes, cgi-bin, or PHP, I wouldn’t call those separate pages.
But for real now: apart from a few overpaid “corporate identity” execs who are used to it from their overloaded powerpoint presentations, who really cares about those split second animations?
I like this idea! Do you think it’s extreme to try and implement dark/light mode using static HTML? I can’t seem to find a good workaround for a javascript-less solution to give people the option to choose to deviate from their system preference.
But it sure feels like overkill to generate a copy of each page just to avoid making someone enable JS to change the colors on their screen… which I don’t even do because I prefer everything in dark mode anyway.
I don’t understand why so many web sites implement a dark mode toggle anyway. If your page uses CSS conditionally on prefers-color-scheme to apply a light theme or dark theme depending on the user’s system preference, why isn’t that enough?
For example, if the user is looking at your page in light theme and suddenly they think their bright screen is hurting their eyes, wouldn’t they change their systempreference or their browser’spreference to dark? (If they don’t solve the problem by just lowering their screen brightness.) After they do so, not only your page but all their other apps would look dark, fixing their problem more thoroughly.
For apps (native or web) the user hangs around in for a long time, I can see some reasons to allow customizing the app’s theme to differ from the system’s. A user of an image editing app might want a light or dark mode depending on the brightness of the images they edit, or a user might want to theme an app’s windows so it’s easily recognizable in their window switcher. But for the average blog website, these reasons don’t apply.
I am curious about how many people use it as well. But it certainly is easier to change by clicking a button in your window than going into your system or browser settings, which makes me think that it would be nice to add. Again, for the imagined person who decides to deviate from their system preference.
Although you’ve made me realize that even thinking about this without putting work into other, known-to-be-used accessibility features is kind of ridiculous. There is lower hanging fruit.
Here’s a concrete example. I generally keep my browser set to dark mode. However, when using dark mode, the online training portal at work switches from black text on a white background to white text on a white background. If I wanted to read the training material, I would need to go into my browser settings and switch to light mode, which then ruins any other tab I would switch to.
If there was a toggle button at the training portal, I could switch off dark mode for that specific site, making the text readable but not breaking my other tabs. Or, if the training portal at work won’t add the button, I could at least re-enable dark mode in every tab whose site had added such a toggle.
Sure, but only on sites that provide a button. It seems a little silly that one bad site should mean that you change your settings on every other site / don’t have your preferred theme on those sites.
Given how widely different colour schemes can vary, even just within the broad realms of “light” and “dark”, I can imagine some users would prefer to see some sites in light mode, even if they want to see everything else in dark mode. It’s the same reason I’ve set my browser to increase the font size for certain websites, despite mostly liking the defaults.
It would be nicer if this could be done at the browser level, rather than individually for each site (i.e. if there was a toggle somewhere in the browser UI to switch toggle between light/dark mode, and if the browser could remember this preference). As it is, a lot of sites that do have this toggle need to either handle the preference server-side (not possible with static sites, unnecessary cookies), handle the preference client-side (FOUC, also unnecessary cookies), or don’t save the preference at all and have the user manually toggle with every visit. None of these options are really ideal.
That said, I still have a theme switcher on my own site, mostly because I wanted to show off that I made two different colour schemes for my website, and that I’m proud of both of them… ;)
I remember the days when you could do <link rel="alternate stylesheet" title="thing" href="..."> and the browser would provide its own nice little ui for switching. Actually, Firefox still does if you look down its menu (view -> page style), but it doesn’t remember your preference across loads or refreshes, so meh, not a good user experience. But hey, page transitions are an IE6 feature coming back again, so maybe alternate stylesheets will too someday.
The prefers dark mode css thing really also ought to be a trivial button on the browser UI too. I’m pretty sure it is somewhere in the F12 things but I can’t even find it so woe on the users lol.
But on the topic in general too, like I think static html is overrated. Remember you can always generate html on demand with a trivial program on the server with these changes and still use all the same browser features…
I’ve been preparing something like this. You can do it with css pseudo selectors and a checkbox: :root:has(#checkbox-id:checked) or so; then you use this to either ‘respect’ the system theme, or invert it.
The problems I’m having with this approach:
navigating away resets the checkbox state
svg and picture elements have support for dark/light system theme, but not for this solution
Yeah, I think I saw the checkbox trick before, but the problems you outline make the site/page/dark and site/page/light solution seem more enticing, since they can avoid especially the state reset issue. I like the idea of respecting/inverting the system theme as a way of preserving a good default, though!
Yeah, as an alternative, for the state issue I was thinking of using a cookie + choose the styles based on it, but that brings a whole host of other “issues”
There’s latency and extra network traffic, though with a static site those should be pretty low.
The UX might get a little weird in some ways — in the case of the site menu, the menu-open state becomes part of the history, so if you open the menu and click a link and go back, the menu’s still open. Then you go back again and it’s the same page but with the menu shut.
I expected the history to fill up as you described, but it seems the implementation avoids that by making the menu close button go back in history if possible. It does that with this HTML (shown unminified):
Doesn’t work as intended on Safari / iOS, and the post filtering also wasn’t visible to me.
The code I quoted does work as intended in Safari on iPadOS 17: it prevents history from being filled when I repeatedly tap the menu button and the menu close button.
Perhaps rather than replying to me, you meant to comment on the article as a whole. I see that on iPadOS, the CSS transition animations don’t work. The page just blinks between states like any other page load.
You’re right, I misunderstood: I thought it was intended that the menu not enter the history at all, but this way is probably better.
Clever! 👍🏻
The animations don’t seem to work for me (I tried enabling JS, still no luck)
Firefox doesn’t support css view transitions.
Yet.
Oh, thanks
I am really confused about this. Is this not the canonical way of making websites for 30 years? Is this about the fact that it has fancy animations? Or is the author so young that the web is just set of html documents with URLs?
Having a separate HTML page for the open state of your navigation menu has never been the standard as far as I’m aware. The standard has been CSS/JavaScript for a decade or so, DHTML for the decade before that, and frames (always “open”) for the decade before that.
Wasn’t DHTML just a fancy name for the practice of using JavaScript to change what is on a page? Is there a reason not to say “JavaScript for the decade before that”?
The Wikipedia page contrasts DHTML with Ajax, but even in the last decade, standard navigation menus wouldn’t use Ajax anyway.
I don’t know what this means. Asking without sarcasm: are you not aware that wesbsites predate JavaScript and were just collections of html documents without interactivity beyond following links and submitting forms?
The most primitive menus, still widely used, are just collections of links with consistent look and positioning across different pages you navigate by clicking on hyperlinks.
Those collections of links were not separate HTML pages, though—except in the case of frames, which I mentioned. Even if they were separate files included with things like Apache includes, cgi-bin, or PHP, I wouldn’t call those separate pages.
Yes, it’s about the fancy animations. You don’t need JavaScript SPAs to have fancy animations between your page states any more.
But for real now: apart from a few overpaid “corporate identity” execs who are used to it from their overloaded powerpoint presentations, who really cares about those split second animations?
This is exactly the kind of time and code savings you can get when you use the platform instead of implementing from scratch. Brilliant!
This is pretty neat. I might steal the idea for my own blog (it’s in my plans to get rid of all JS).
Statically generated pages are perfect for this because there’s little latency and you can cache that very well.
I like this idea! Do you think it’s extreme to try and implement dark/light mode using static HTML? I can’t seem to find a good workaround for a javascript-less solution to give people the option to choose to deviate from their system preference.
But it sure feels like overkill to generate a copy of each page just to avoid making someone enable JS to change the colors on their screen… which I don’t even do because I prefer everything in dark mode anyway.
There’s a CSS-only way (using a heavily restyled checkbox) to toggle other CSS attributes:
Today I learned that
light-dark()is a thing! Thanks!I’m using a similar idea for my own dark mode checkbox: https://isuffix.com (website is still being built).
GP comment might enjoy more examples of CSS
:has()in this blog post: https://www.joshwcomeau.com/css/has/I don’t understand why so many web sites implement a dark mode toggle anyway. If your page uses CSS conditionally on
prefers-color-schemeto apply a light theme or dark theme depending on the user’s system preference, why isn’t that enough?For example, if the user is looking at your page in light theme and suddenly they think their bright screen is hurting their eyes, wouldn’t they change their system preference or their browser’s preference to dark? (If they don’t solve the problem by just lowering their screen brightness.) After they do so, not only your page but all their other apps would look dark, fixing their problem more thoroughly.
For apps (native or web) the user hangs around in for a long time, I can see some reasons to allow customizing the app’s theme to differ from the system’s. A user of an image editing app might want a light or dark mode depending on the brightness of the images they edit, or a user might want to theme an app’s windows so it’s easily recognizable in their window switcher. But for the average blog website, these reasons don’t apply.
I am curious about how many people use it as well. But it certainly is easier to change by clicking a button in your window than going into your system or browser settings, which makes me think that it would be nice to add. Again, for the imagined person who decides to deviate from their system preference.
Although you’ve made me realize that even thinking about this without putting work into other, known-to-be-used accessibility features is kind of ridiculous. There is lower hanging fruit.
Here’s a concrete example. I generally keep my browser set to dark mode. However, when using dark mode, the online training portal at work switches from black text on a white background to white text on a white background. If I wanted to read the training material, I would need to go into my browser settings and switch to light mode, which then ruins any other tab I would switch to.
If there was a toggle button at the training portal, I could switch off dark mode for that specific site, making the text readable but not breaking my other tabs. Or, if the training portal at work won’t add the button, I could at least re-enable dark mode in every tab whose site had added such a toggle.
Or, hear me out, instead of adding javascript to allow users to work around its broken css, the training portal developers could fix its css?
(Browsers should have an easy per-site dork mode toggle like the reader mode toggle.)
I feel like this is something to fix with stylus or a user script, maybe?
sounds like the button fixes it
Sure, but only on sites that provide a button. It seems a little silly that one bad site should mean that you change your settings on every other site / don’t have your preferred theme on those sites.
Or the DarkReader extension or similar.
Given how widely different colour schemes can vary, even just within the broad realms of “light” and “dark”, I can imagine some users would prefer to see some sites in light mode, even if they want to see everything else in dark mode. It’s the same reason I’ve set my browser to increase the font size for certain websites, despite mostly liking the defaults.
It would be nicer if this could be done at the browser level, rather than individually for each site (i.e. if there was a toggle somewhere in the browser UI to switch toggle between light/dark mode, and if the browser could remember this preference). As it is, a lot of sites that do have this toggle need to either handle the preference server-side (not possible with static sites, unnecessary cookies), handle the preference client-side (FOUC, also unnecessary cookies), or don’t save the preference at all and have the user manually toggle with every visit. None of these options are really ideal.
That said, I still have a theme switcher on my own site, mostly because I wanted to show off that I made two different colour schemes for my website, and that I’m proud of both of them… ;)
I remember the days when you could do
<link rel="alternate stylesheet" title="thing" href="...">and the browser would provide its own nice little ui for switching. Actually, Firefox still does if you look down its menu (view -> page style), but it doesn’t remember your preference across loads or refreshes, so meh, not a good user experience. But hey, page transitions are an IE6 feature coming back again, so maybe alternate stylesheets will too someday.The prefers dark mode css thing really also ought to be a trivial button on the browser UI too. I’m pretty sure it is somewhere in the F12 things but I can’t even find it so woe on the users lol.
But on the topic in general too, like I think static html is overrated. Remember you can always generate html on demand with a trivial program on the server with these changes and still use all the same browser features…
I’ve been preparing something like this. You can do it with css pseudo selectors and a checkbox:
:root:has(#checkbox-id:checked)or so; then you use this to either ‘respect’ the system theme, or invert it.The problems I’m having with this approach:
Yeah, I think I saw the checkbox trick before, but the problems you outline make the
site/page/darkandsite/page/lightsolution seem more enticing, since they can avoid especially the state reset issue. I like the idea of respecting/inverting the system theme as a way of preserving a good default, though!Yeah, as an alternative, for the state issue I was thinking of using a cookie + choose the styles based on it, but that brings a whole host of other “issues”
I love the idea. It is 100% in my wheelhouse and my aesthetic. I want to use this for everything.
However
I probably need to be reminded of this in a year or two.