Ask the User

On Twitter, I rarely vote when a poll shows up in my timeline. But I did participate when Remy Sharp asked if we should do Syntax Highlighting on the client or server side. Client, sure thing. It’s what I do on my blog. Otherwise I would have to teach my static site generator to prepare everything upfront.

It got even more interesting when Remy wrote a follow-up blog post on the subject, where instead of relying on gut feeling he went trough the trouble of creating tests for both cases. Concluding that pre-rendering pages, i.e. adding Syntax Highlighting on the server, is the way to go these days. Initially he too thought otherwise, but the tests revealed this wasn’t the case. At least not anymore, back in the day the client was the only option. Alas, time changes everything. My situation is not so different, I’ve also been doing this thing for a long time. We should challenge old assumptions every once in a while.

How about a third option?

From Remy’s test we can derive that, once compressed, the already enhanced HTML performs better than sending an accompanying JavaScript library like PrismJS to do the job. While I won’t argue with the facts, I am still reluctant to go ahead and inject tons of <span>s in my code blocks. Maybe I wanted the client to win after all. Should I go ahead and create tests to figure out if the playing field would level for recurring visitors, i.e. those who have the JavaScript library already in cache?

No. Instead, I considered an alternative to find a way out of the dilemma. Needless to say, on technical blogs Syntax Highlighting makes a lot of sense. But let’s not forget that it is still an enhancement, not a requirement. So get the best of both worlds, how about we start off with plain code inside a <pre> tag, and give the user a choice. Said choice would be another job for the client. All I need to do is add a script that supplements each code block with a toggle to enable Syntax Highlighting. This means users will only get the highlighting library once they actively ask for it. But when they do, I will of course persist the user’s choice. As I do not use cookies on my site, the user preference will be stored in localStorage.

I could simply enhance an existing script that already defers loading of PrismJS, because what it does is check upfront if there are code blocks on a page, so even today the library will only be added to a page if needed. Many server-side fans commented in Remy’s poll that they did not like flash of unstyled content (FOUC). Well, Highlighting on my blog does not cause any reflow by adding line numbers, nor do I use a handwriting font for comments or anything else that would. It only changes the text color, and I find those color flashes to be acceptable. Accessibility-wise I need to do a bit of research, simply hiding the toggle with aria-hidden crossed my mind, but that might not be ideal.

We could even go beyond a boolean toggle, and instead present a list of different color schemes to the user. E.g., one option that plays nicely with the colors of the blog, but also some schemes from popular IDEs.

When I find the time, I will add just that to my blog.

Addendum: If enhancing each code block is not your thing, you could just add one central toggle and bury it somewhere under “settings”, but doing so would most likely mean that visitors to your site will never see the toggle and its options.