Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

1–4 are good, but 5 is not. The checkbox hack is decent in a few places (though I’d say <details> is normally a better choice now, and the checkbox hack should be accompanied by certain ARIA properties and augmented with some JavaScript to twiddle properties as it’s used), but dark mode is not one of them. The checkbox hack is only suitable for transient state that you actively don’t want to persist over page loads. Probably the most popular historical application of it is hamburger menus (but <details> or `:hover, :focus-within` are better for that now). I think a more reasonable solution for dark mode is the media query (prefers-color-scheme: dark), following the browser preference by default and augmented by JavaScript to allow overriding that. https://chrismorgan.info/blog/dark-theme-implementation/ describes my own implementation, which is the most comprehensive and efficient client-side-only implementation that I know of, as perfect as it’s possible to be while being client-side-only and without getting into service workers.

Something I don't see talked about often is a variation on the "checkbox hack": using radio groups. The checkbox hack gives you a nice binary piece of state without JS, but using radio buttons gives you any number of options that you need.

For a light-mode/dark-mode toggle that doesn't use JS, I would suggest using radio buttons. It's really a situation that calls for 3 distinct states: follow the system preferences, override to force light mode, and override to force dark mode.

---

I totally agree though that JS should be used to augment, especially to save the state across page loads. At best, Firefox will autofill radio buttons across page reloads within a session, but that's not sufficient enough.

I was recently considering the approach of keeping this transient state in the URL somehow: the only place that makes sense (for CSS to access it) is in the fragment. Rather than toggling a checkbox or radio group, link to a fragment of the page. This gets tricky with multiple pieces of state though; you have to permute all of the state on the page into increasingly long (or unreadable) fragments (eg. `example.com/my-page.html#color-scheme-override-dark-and-sort-by-title-asc`). However on the plus side, you get state for free _and_ can share your set of state with other people (which makes sense for page state like sorting and filtering, but not so much color scheme overrides).

I use 5 for the hamburger menu on one of my sites. It works really effectively too, means I could build the entire site without writing a single line of Javascript (I've got nothing against Javascript but given it's ostensibly just a collection of man pages I did question the worth of adding any Javascript)

Wouldn't details and summary be better for a hamburger menu, assuming you can style them the way you want? Using a checkbox seems problematic for accessibility; a screen reader user certainly wouldn't expect to open a hamburger menu by checking a checkbox.

The hamburger is only needed for the mobile view (to show/hide navigation that is always present on the desktop view) so there shouldn't be any issues for screen readers. But the site is open source (as it's part of an open source project) and I'm happy to accept any PRs to fix any accessibility issues I might have missed.

Blind people use mobile devices, too.

The checkbox hack can be replaced with :active in many cases.

:active is completely different and never a suitable replacement for the checkbox hack: it only ever matches while the primary mouse button is being held down, and is keyboard-inaccessible; the checkbox hack is about toggling state on click or key stroke.

Oops, I meant :target.

:target is dubious at best: it messes with your scroll position, and you can only use it for one thing in a document.

Historically it was also rather buggy in most browsers, though hopefully that’s sorted out now. (A decade ago, Firefox was fine, but IE and Chromium both had significant bugs, might have been to do with back/forward not recalculating :target or something like that. When I last seriously used :target in 2016 or so, on a multipage-in-one-document résumé, I think they were down to fairly minor bugs.)

Reply on news.ycombinator.com