Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
I've added a dark mode toggle web component to add a dark mode to the htmx.org website. The web component just adds
.dark
to the body element, but it also checks for user preference (viaprefers-color-scheme: dark
and LocalStorage; it also adds the dark mode state to LocalStorage.The preference checks enable dark mode to persist across page navigation, and they are the reason the toggle was not implemented in hyperscript. The body element class toggle is easy enough to do in hyperscript, but it's also the least complicated part of a dark mode toggle; handling persistence is the hard(er) part -- and, afaik, is out of scope for hyperscript? Since javascript is required to handle persistence, I felt it was worth it to use the web component for the entire toggle (I've heard locality of behavior is popular here).
I refactored the CSS colors into variables to ease the swap. I normalized the (wide variety!) of shades of gray into 2 foreground and 2 background colors, and handled variations using alpha. I retained the "brand" blue in the logos (
var(--x-color)
), but I switched to a lighter blue in dark mode for links, to keep the site in happy a11y territory.I noticed a few places where other CSS normalization and optimization could occur, but I tried to keep those out of this PR. (If y'all express an interest in that, I'd be happy to add those as another PR.) The only "optimization" that I didn't remove is the addition of a
note
class (used in the index's news and in the docs page); I don't want to remove the ability of the content author to add css directly in the .md files, but this particular repetition seemed like something that could be extracted -- the author only needs to remember one class. I did NOT add thenote
class to anywhere else in the *.md files, since they didn't have that styling, but that seems like something worth trying.Corresponding issue:
No issue, just my own screeching
Testing
Checklist
master
for website changes,dev
forsource changes)
approved via an issue
npm run test
) and verified that it succeeded (I didn't really; I only touched CSS. It was like that when I got here!)