For a while now the site has used the default theme, Twenty Twenty One. I liked it okay, but one thing that bothered me was that the dark mode wasn’t customizable, was kind of bland.
The other thing to know is that I use Stylus to clean up or modify styles on various websites I visit. For some time I’ve been using a semi-dark theme (the same light gray background as the light mode background here) on many news sites, and occasionally a dark version on others (again, same background as the dark theme here). That kind of daily testing led me to find it preferable, and so I wanted to bring that design to this site.
Browsing through Google’s selection, many fonts come close to being great but had at least one or two flaws I couldn’t abide.
The basic premise of the light theme is that websites don’t need to be white-backgrounds. We have shades of gray to use here. And that dark modes don’t need to be white-on-black. Again, we have shades. For the most part, I would be happy to use light themes if they weren’t pure white. All the web designers that shook their fists at the need to create dark variants could have made a compromise, but I haven’t seen any of them do so.
Even at night, the light theme of this site isn’t particularly bad to my eyes, though the dark mode is certainly nicer.
I found underscores.me, a starter theme. It provided a solid base to build on. I later found out that WordPress is soon (sometime next year) to release a “Block theme” built for their new Gutenberg blocks system. I may eventually rebuild for that, or switch to it. It offers “full site editing,” which may kill off traditional themes. I’m not entirely sold yet, but I’m keeping an open mind and waiting to try it out and see what it offers.
I tried to add some functionality with plugins, but they mostly don’t offer an off-switch for their default styles, and trying to dequeue their styles is hit-or-miss, so I built more functionality into the theme itself. If I end up migrating to the new system, I may have to rework that functionality into plugins.
The one decision that skipped a plugin but I didn’t implement myself is code highlighting. After looking at client-side (JavaScript) options and server-side (plugin) options for code highlighting, I decided to go with neither. I can run code through pygmentize when I compose an article, and then I can add the markup directly to the post. I already self-handle other elements, like images. So if I get the itch to actually highlight code, that’s what I’ll do.
One of the big non-technical challenges was finding good typefaces. I opted to use Google Fonts to load nicer typefaces here. (I load them with WebFontLoader.) Browsing through Google’s selection, many fonts come close to being great but had at least one or two flaws I couldn’t abide. One had an inverted at-symbol (@), another had a capital C that looked too much like a G. Most sans-serif fonts don’t properly distinguish between uppercase I and lowercase L.
In the end, I dropped trying to have a separate serif face for headings, in part to keep the site light, and in part because trying to find two faces was too much.
CSS Fun
Having not done much web development in a long while, here are some of the newer things I used in building the stylesheet.
:where()
Having been out of the loop, I didn’t realize :is() and :where() existed. I only use the latter, as it doesn’t influence the scoring of selectors. It lets you do things like:
.recipe :where(.ingredient, .tool, .container) {
font-weight: bold;
}
This saves you creating three separate selectors if you want all “important” items under a recipe to be boldfaced.
clamp()
I knew that math functions existed, but clamp() is really nice. You give it three values:
- minimum
- variable
- maximum
And it will let the outcome vary only within the bounds you set. Most of the time the variable will involve something with vw units, so that the outcome varies based on the screen width, but there are other ways to use it.
Custom property fallbacks
I’ve used custom properties in my user styles for awhile, so that I don’t have to recreate things like colors for every site I create a custom style for. But I didn’t know there are fallbacks. I only use them for filling the SVGs in the social media buttons:
html:not([dark]) .soc-fill,
html[dark] .soc-link:focus-visible .soc-fill {
fill: var(--ic-soc-c0, #000);
}
html[dark] .soc-fill,
html:not([dark]) .soc-link:focus-visible .soc-fill {
fill: var(--ic-soc-c1, #FFF);
}
I set fill values (--ic-soc-cN) for some icons, if the service calls for a particular color in their brand guide, but if not I can fallback to black or white (depending on the dark or light theme and whether or not keyboard focus is happening).
Other small bits
Testing in chromium taught me about will-change that hints the browser to expect repaints of an element. It probably isn’t that necessary given it’s only for the theme-mode toggle in the upper right, but it’s cool to know about. I was also able to use a media query for prefers-reduced-motion to stop that animation if someone has a relevant OS setting turned on.
I tried to get accessibility correct. Some of that was helped by WordPress itself, other parts helped by the underscores base. Proper accessibility design helps everyone, including people in early stages of a sight disorder or even someone who’s stressed or drunk or tired.
To improve accessibility, I removed placeholder text in form inputs. After trouble finding good colors that were within the contrast bounds, I did some thinking and reading. I decided that the only real purpose of placeholder text is to make forms look less plain. Multi-field forms need visible labels anyway, and with those the placeholders don’t really add anything to the design.
If you’re relying on hidden labels being read by screen-readers, that leaves people who may have some accessibility needs out in the cold. The exception is single-field forms (like search), where the button next to the field provides enough information for people without screen readers.
I also tried to make keyboard navigation work correctly and with good focus coverage. I actually like how the focus looks more than the lesser design like hovering. I might eventually collapse them into the same design, though I have slight concerns that could be too confusing. Having separate styles for :hover and :focus-visible seems cleaner.
Credits
The darkmode toggle button and its JavaScript is slightly modified from Henry Egloff: “How to Code a Simple Dark Mode Toggle”.
After looking at the options, I went with remedy.css for a “reset” (github: Jen Simmons: cssremedy). I still didn’t use most of it. I’m not targeting Internet Explorer. In general I don’t want to target browsers more than a few years old.
I got a lot of help from the usual:
(Probably forgot some others. It’s the Internet, lots of good and helpful stuff around! Many thanks!)
I’m sure there’s other things I forgot. But that’s enough words for now. Hope visitors enjoy the new look.