The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Ink Cream, the New Theme

Finally a fresh coat of paint on this old heap! Sit and read some of how it came to be.

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.

Killing Comic Sans

How not to see Comic Sans.

Sure, you could just uninstall the Microsoft core fonts (they are non-free, after all), but they’re nice to have around (I guess?). Or you could just remove Comic Sans itself, but maybe you’ll one day want to use it for good or ill (who knows?) So instead you might turn to fontconfig.

First you might try a substitution rule like:

<alias>
    <family>Comic Sans MS</family>
    <prefer><family>DejaVu Sans</family></prefer>
</alias>

The prefer families specified should (?) be used before using the matched font family, even if it exists. But in testing, that didn’t work for me. Don’t force it, use a bigger hammer.

So I switched to a match/edit rule like:

<match target="font">
    <test name="family" compare="eq" qual="any">
        <string>Comic Sans MS</string>
    </test>
    <edit name="family" mode="assign">
        <string>DejaVu Sans</string>
    </edit>
</match>

This worked, but was too big of a hammer for my taste. For example, in gedit font selection it no longer says, “Comic Sans MS.” It just says, “DejaVu Sans.” What we’re after is substitution of the face, not the whole entry.

As I’m not in the habit of using Comic Sans by choice, the target of the exercise is the web. Ah, but it’s much easier to replace the font for the web. So we walk away from fontconfig and walk over to Stylish (or userstyle.css if you don’t want an add-on to help).

Now we just need a rule that tells the browser, “replace Comic Sans when you see it.” In comes @font-face. We can use this to define, for the browser, what the meaning of a particular font is:

@font-face {
    font-family: "Comic Sans MS";
    src: local("DejaVu Sans");
}

Great! Well, great-ish. We can’t specify the alias “sans-serif” because it’s an alias. That means if you change which font your alias uses (in this case, away from DejaVu Sans), it will require you to update your style rule.

We have limited options here. You could specify the font-weight, but that will interfere with the site’s own weighting. The best case is to use a distinctive replacement font. Or just give up (my choice in this case). Defeating Comic Sans is enough, no need to gloat.

Customizing the Web

Small example of how modifying your web can be useful.

I use the web quite a bit, and one of the things I do quite often is customize my experience on sites I frequent. Most of that customization comes via Stylish and Scriptish (the latter a fork of Grease Monkey).

Some of the things I customize are minor, like page aesthetics. Some I consider more important. Take Google Search for example. Did you know some of your search results are censored? This is thanks to laws like the Digital Millennium Copyright Act (DMCA). Google is good enough to notify you when censorship has occurred.

But only if you scroll to the bottom of the search page. Which you may not do for quick, one-off searches. This is the equivalent to newspapers printing important news on page 8N which is otherwise a full page of ads.

But thanks to Stylish:

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("google.com") {
  #mfr {
    position: absolute !important;
    top: -20px !important;
    right: 0px !important;
    width: 300px !important;
    background-color: #FCC !important;
    font-size: 1.2em !important;
  }
}

This adds a bit of styling to the notice and throws it at the top-left of the search results.

With most software this wouldn’t be possible. Without the open web that notice (if there at all) would be permanently stuck down at the bottom. Maybe I would adopt the practice of always looking for it, but it’s doubtful.

Instead, I can remain aware of the prevalence of censored results. I can find out more.

The challenge is opening up this technology to those who don’t know CSS, JavaScript, HTML, or how to debug those technologies (as modifying the page often requires understanding it rather than simple repositioning like above). There are ways to do that, but so far they seem limited to having programmers hand ready-made solutions to novices (eg, via sharing snippets like that above).

The problem with that approach is that it limits the idea pool to those who either can implement a modification themselves or knows someone who can.