[ this is not finished. it will never be finished. fuck you ]
(note to self: if this becomes 100+ lines, just make it a fucking blog post jesus christ)
Yeah, it’s been a while since I made an update to this site. But hey! I got an actual post this time!!!!
Since I’m writing this while I am still working on editing the post, I’m going to leave a checklist here of things I want to work on surrounding the site before I publish a new article.
Syntax Highlighting
This post uses a lot of code blocks and code strips (what I’m calling “monospace” formatting). I’m really proud of where my
syntax highlighting and code block functionality is right now. However, I want to make a couple of tweaks and updates to make
my implementation first-class.
First, I need to do a quick check on whether syntax highlighting in code blocks works without JavaScript. In my eyes, it should, since
all of the processing happens on the server-side and all the client gets is a bunch of <span>’s with different colors attached to them.
If it doesn’t, I need to figure out why and fix that before publishing.
Ideally, my site should require as little client-side scripting as possible, if any. The main reason I moved away from Zonelets (a popular blog template for Neocities) is because of how it required client-side scripting to even function properly and let you see what posts are on the site. Especially after I moved away from Neocities, a platform that is built around banning server-side scripting, that reliance on client-side scripting to make up for that slack seemed kinda silly now that I can use server-side scripting.
I know it’s kinda silly to want as little JS as possible on a site powered by JS/TS in the backend and on a platform designed around single page applications & routing… but hey, a girl can have her cake and eat it too sometimes.
The other main thing regarding syntax highlighting I wanted to check is how to get it to work with Tailwind’s automatic theming. Currently, the site switches from light to dark mode with the browser / OS — there is no way for the user to set it differently. That’s something I want to change in the future, but for now it makes things Just Work™ a little better because I can use Tailwind’s automatic light/dark theming system to change colors based on theme.
Before, I just had the MDXCodeBlock component change its entire theme depending on whether the browser is in light or dark mode.
This had two problems: the theme only updated once, and it updated slightly after the rest of the site is themed properly. The theme
is set to light mode by default, so in dark mode, the theme would be too dark for half a second before the theme check actually goes through
and the code block theming fixes itself. That is very bad.
My thinking is that since what gets sent to the browser is a bunch of <span>’s with colors slapped on them anyway… what if I make
those individual colors themed instead of changing what colors to slap on depending on the theme? The easiest way to do this would be
to make a new theme where instead of defining the color by a color: attribute in style, the color is defined by classes. That way,
not only can I build a theme with my existing Tailwind colors and themed around my site, but I can also give all tokens two colors
— one for light, and one for dark — using the dark: prefix I already use in the rest of my site.