I Added Syntax Highlighting Using the 11ty PrismJS Plugin

One thing I like about 11ty is that common tasks for development oriented blogs are easily handled and syntax highlighting is no exception.

I installed the Syntax Highlighting Plugin just like the documentation asked me to. Then, I had to modify my code blocks in my blog post Markdown files to indicate what language they were. Thankfully, I had only written two articles so far that contained code blocks. Nothing so far deviates from what the documentation says.

When I started considering the compile process, however, I had a few considerations.

Only using the CSS when there was code on the page

The first thing to note is that I inline my CSS. My thinking is that most users visiting my site aren’t likely to have my CSS file cached—either because they’re on my site for the first time or because it has been long enough since they visited my site and the file has expired.

Currently, I only have two templates: my universal template and my blog post template. I inline additional CSS in my blog post template that isn’t needed anywhere else on the site. As such, the first thing I did was add the PrismJS theme to my template and see how it looked. No surprise, it looked great.

But what if I have no code on the page? Why am I loading the CSS for every blog post? Easy enough. I added a yaml parameter of hascode: true. And then I check for that parameter in my template.

{% if hascode %}
    <link rel="stylesheet" ... >
{% endif %}

That was nice. But as I mentioned, why am I creating an HTTP request when I usually inline my CSS? No problem. A simple copy/paste and that was done.

Light and Dark Mode

Initially, because the themes are relatively small, I thought about finding a theme that worked for light mode and one for dark mode, wrapping them in prefers-color-scheme. But that still seemed excessive. I found the Duotone Light theme that I thought looked best for my light mode and then realized that much of it still worked in dark mode if I gave it a couple tweaks.

The first tweak was to use the light-dark declaration I had already had on my pre tags when I launched:

background: light-dark(#FFFFFF50, #00000050);

I double-checked and noticed that the selector colour didn’t work in dark mode. So, instead of just trying to find a colour that would work, I decided to use a CSS colour function to solve the problem.

color: light-dark(#2d2006, hsl(from #2d2006 h s calc(l + 80)));

This uses the hsl function to shift the luminosity of the colour from the light mode version.

This is a bit of overkill as I could just take the rendered colour and put that in place of the function but sometimes it’s just fun to try new things.

Pretty

I really like how the code blocks look now, although I don’t love that there’s no indication that the code has overflowed the container if you have scrollbars turned off by default—which most people do these days. Once we get scroll-state container queries supported across all major browsers, maybe I’ll deal with it then.