My last post was the first on this blog to include pre-formatted code in its body; namely the <pre> and <code> tags. After publishing that post, I realized that my CSS rules for code were pretty crumby. Styling code on a web page works the same as any other text on the screen, but the nature of code forces you to make some choices about how to present it.

Code is typically displayed in a monospace font; on the web and in a text editor. This itself is not a problem, but we are forced to decide how we want to treat code that appears in a block of prose, for example. Mixing variable and fixed-width fonts (or any number of different fonts) within a single paragraph can be visually offputting. This is, however, common practice with code-in-text on the web. Finding the right font and styling it alongside the main font can be tricky, to say the least.

The other issue is that lines of code can be long. When writing code, your editor might be able to break lines of code where it makes sense to, or you might choose to not have long lines break at all. Every programming language differs in the way its code should be wrapped (if at all). In a web page, we can’t wrap the code in our codeblocks this way without some serious gymnastics and probably some Javascript. We have to rely on the algorithm the browser ordinarily uses to wrap lines—or we could just not wrap at all.

styling unwrapped blocks of code

In your text editor, not wrapping long lines is fine, but on a web page a line that extends past the width of the text block is irritating. Before we had handheld devices, this was less of an annoyance, but scrolling vertically through a page that veers to the left or right slightly just because a long line exists somewhere on that page is, in my opinion, far from ideal. We can, of course, make it so that the width of the codeblock is fixed and instead allow its contents to be scrolled (which is also a common practice online). The problem here is that a big scrollbar will appear when you go to scroll the block, often times blocking the text you are trying to look at. There are good reasons scrollbars exist, but they are kind of ugly and wonky, and in this scenario, I just can’t abide them cluttering the view. So how about we disable them:

pre code {
    overflow-x: hidden;
}

Hmm… it turns out that if we hide the scrollbar, then scrolling is also disabled! For a long time, getting around this required some hacky workarounds, but now there is a simple fix:

pre code {
    scrollbar-width: none;
}

Now we can hide the scrollbar and still be able to scroll! This setting has only been around for a year or so, but it is widely supported and is accepted by the W3C CSS validator. It does come at a cost to accessibility, though. Depending on what you are doing, this may not matter. Admittedly, not everything on my blog is optimally accessible, but this is one place where it feels worth it to not cut corners. So rather than eliminating the scrollbar, I have instead just added padding around the code so that the scrollbar won’t overlap it:

pre {
    padding: 0 1em 0 1em;
}

pre code {
    display: block;
    overflow-x: auto;
    padding: 1.5em 0 1.5em 0;
}

Deponding on someone’s local settings, the scrollbar could still end up overlapping with the text. My testing has shown that 1.5em is a fairly safe amount of padding that doesn’t introduce an excessive amount of white space.

general styling of code

Now that we have a block of code that scrolls without the annoyance of an overlapping scrollbar, how should we style the actual contents? In your time surfing the web, it is likely that you have come across many a fancy codeblock. A common approach is to have light text against a dark background (like a typical terminal emulator) and to even highlight the syntax of the code itself. For this blog I decided to do neither of these things.

Syntax highlighting is helpful when writing code, but it seems unnecessary on this blog in particular. Even in a text editor, I find that most color themes use colored highlighting so excessively that it ceases to serve its purpose as highlighting. It becomes visually distracting and overly stimulating. Of course, great color themes are possible, and they do exist. But this blog uses color somewhat sparingly, having just a normal and light foreground color, a background color, and one accent color. An ambush of color in the middle of that would be jarring.

I decided to keep the code blocks monochromatic, using a slightly lighter color for the text, and a slightly smaller font size. This is all wrapped up in a modest border:

code {
    font-family: var(--monospace);
    font-size: 90%;
    color: var(--text-light);    
}

pre {
    margin-bottom: 1.5em;
    padding: 0 1em 0 1em;
    border-color: var(--text-light);
    border-style: solid;
    border-width: .05em .15em .15em .05em;
    font-size: 90%;
}

pre code {
    display: block;
    color: var(--text-light);
    overflow-x: auto;
    padding: 1.5em 0 1.5em 0;
}

But what about code that appears outside of a code block? I am not too keen on the idea of mixing fonts within a paragraph, especially when the guest font is fixed-width. I know that this is common practice on the web, but a lot of times it feels so awkward. Ultimately, I decided to compromise for the special case of code. What I came up with is hopefully subtle enough to flow with the rest of the text while also sufficiently distingushing the code from it:

:not(pre) > code {
    text-size: 100%;
    color: var(--text-light);
    font-weight: bold;
}

Rather than changing the background, I decided to make the code text a lighter color while also increasing its weight. This way it stands out but not too much that it snags the reader’s eye when reading through a block of text.