https://chrismorgan.info
If I wanted to know I’d look at the Referer header;
and if it isn’t there, it’s probably for a good reason.
You abuse your users by adding that to the link.
https://chrismorgan.info
Hey! That one’s even worse, UTM parameters are for me to use, not you.
Leave my URLs alone.
So I’ve decided to try a blanket ban for this site: no unauthorised query strings.
At present I don’t use any query strings.
If I ever start using any query strings, I’ll allow only known parameters.
(In past times I used ?t=… and ?h=… cache-busting URLs for stylesheet URLs;
and I decided I’m okay breaking such requests; there shouldn’t be any legitimate ones.)
Want to see what happens if you add a query string? Go ahead, try it.
It’s my website: I can do what I want with it.
And you can do what you want with yours!
This is currently implemented in my Caddyfile. ]]>
In 2013, I started my website, using Hyde.
In 2016–2018, I reimplemented the site on Lektor and redesigned it twice (including migrating all content, which was actually fairly involved in at least one of the designs), but decided I didn’t like the direction and never shipped it (although it was genuinely finished).
In 2019, I migrated to Zola, making various changes but keeping all content.
I kept on writing various things over time—I have a bunch of half-finished draft articles and a very long file of stubs in various stages of completion—but found the bar of polish I’d set to be too high, and didn’t end up publishing much.
I became fed up with Zola, the constraints of other people’s static site generators, and the traditional structure of my site altogether.
In 2026, I’ve decided to archive all the old site and content, because I have a significantly different vision of what I want now.
Existing URLs of all public resources (HTML, Atom, SVG) and most subresources will continue to work, but at least for now they won’t be integrated with the new site, and may never be updated.
I’m abandoning all /blog/… structure (/blog/, /blog/slug/, /blog/tags/slug/{,feed.xml}).
/feed.xml will continue to work, redirecting to its new name /*.feed. I have archived all the existing feed items to a second page (it had grown to 425 kB and was possibly my most-requested file), and I will probably paginate my feeds more in the future. (I don’t know how many feed readers support pagination, but the content normal people want to fetch will always be on page one, so it doesn’t matter anyway—it’s more a foolish perfectionism that has me keeping all content theoretically accessible through feeds.)
Theming is implemented differently now, and I decided not to migrate settings transparently (it’d slightly help a very few people, at a small cost to everyone). I patched the old site to read the new settings, but I removed its theme switcher out of laziness.
Old site: other than a few undated pages of special purpose (e.g. /about/, /hire-me/),
all content was in /blog/slug/.
I used a single taxonomy, /blog/tags/slug/.
This exposed a philosophical aspect, too:
almost all was blog post, private until complete, then published, with minimal updates (only for corrections or changes like updating rustc output—rust-fizzbuzz was the most-updated by far over the years, as rustc changes several times required more extensive updates, because it broke a point that I was making, due to introducing non-lexical lifetimes, or automatically hoisting temporary values, or no longer mentioning lifetimes in some error messages—several changes that improved the language and the beginner experience, but at a significant cost to mental model pedagogy, quite possibly making it harder to become expert).
Overall, it tended toward append-only.
New site: I want to play with a different approach: no more tags/categories/taxonomies, I’m aiming for a directed graph with edges powered by link relations ( Also, it’ll be a bit more reminiscent of a wiki. Often editing existing content rather than appending a new blog posts. A lot more small pages and interlinking. Also publishing incomplete stuff, so marked, and stuff in different stages of polish.
(A lot of this architecture has been implemented, but the full implications are not yet apparent mostly due to a lack of content.)
Old URLs all ended with a trailing slash, and were mostly /blog/slug/.
New URLs are, at least for now, entirely flat, just /slug. I may introduce other patterns in the future.
Thus / itself was the only conflicting URL, so I moved it to /pre-2026-index.html.
Hierarchical URLs work well when your structure is tree-based. Mine is not going to be, any more. Many pages will definitely have a primary parent, but at least for now I don’t want that to influence URLs.
I considered timestamped URLs (such as /2026/04/07/2026-website), but decided against them. A lot of content will not be dated, and the dividing line between dated and undated content will not always be clear and may change.
Settings previously used Local Storage. Now I’m using cookies for a couple of few reasons:
Dev mode (which I’ll get back to below) has to be a cookie,
so the server can send back a different response from the same URL.
(Alternatives: serve content from multiple URLs,
or depend on a service worker that proxies requests,
adding an extra header when in dev mode.)
I want it to work as completely as possible without JavaScript.
It’s easy enough to lean on Earlier on I was also thinking about the most reliable ways to avoid a Flash of Unstyled Content
(FOUC; most notably, a brief flash of white background when in dark mode),
and that the approach I was formerly using required the prefs elements and scripting to be early in the document,
whereas I’d like to shift them after the content,
but I ended up realising that, without persistence and thus with JS permitted for applying prefs from local storage,
there were alternatives to the way I was doing it.
In the end, it’s nicest for the client if the server sets the load-time preferences in The Caddy configuration and templating to support this isn’t too bad. My loosely-golfed JavaScript, however, is: partly deliberately so, even though the main reason I shrank it so aggressively was because it had to be early in the document at that time (I only implemented the server actually filling in the prefs on root attributes in the day before publishing).
Then the prefs elements and styles and all can come at the end, which is especially best for browsers that don’t support I have Ideas.
Do you remember those “under construction” banners and GIFs of the ’90s (loads 941 images totalling 9 MB)? They tend to depict a work site and the notion of caution or danger.
A building construction zone is a dangerous place: there will be things to trip over, fall into, and have fall on you.
Children may still want to play there, because things are interesting.
A website construction zone is a place where you can safely poke and prod.
This site is very much under construction. Come take a look! Oh? You say it all looks minified?
Turn on dev mode in the (or set the cookie What’s implemented so far doesn’t actually reflect my ultimate plans very well—it’s still comparatively traditional.
I also haven’t integrated my own lightweight markup language into it yet, although it will be central in the long run. But although I’ve been doing all my writing in it for five years, I only got serious about implementing it last year and haven’t finished.
You’ll see my grand plan as it unfolds, but I’ll mention a few things:
It was a small part of an idea I had for an about page, partly to do with getting a job.
I never actually shared it anywhere.
Other than changing mouseover/mouseout to mouseenter/mouseleave (almost enough to tick off “Fix all the weird glitches with it”)
and a few small tweaks to reconcile it with my site styles
(including namespacing classes to this page, for future compatibility),
I have not modified it at all.
I would implement it better now, especially around making it render better when zoomed in.
Click on it! Hover the clock! Sorry mobile users, it won’t work particularly well for you.
New direction
Structure
<link rel> and <a rel>). This is more flexible than mere tags: you get subtags (up), series (prev/next/first/last), and tags are themselves pages in a more real sense than with tags (even though I already made my tag pages more custom than most ever do, fighting against Zola to do so).
URL styles
How preferences are stored, and the implications
:checked to change styles with only CSS,
but you can’t persist them without either JS or a form submission that returns cookies.
<html class=… .
<dialog> or popover (old browsers, and all current text-mode browsers that I know of).
🚧 Under construction 🏗️
view-source: everything! Have fun!
dev=1 by some other means) and the server will give it to you unminified.
Glimpses of my plans
Something I made a decade ago