Site preferences,
and what they all mean
In the footer there’s a you can click to show a panel;
(or if this above you fancy, then it too will raise the pane—)
You’ll find within a range for creativity a channel:
A bunch of things you never saw before, or will again.
Firstly, choose your body text: serif or else sans;
I prefer the serifs, but then tea is not my cup.
Headings will not follow this, and code has its own plans;
Add a user stylesheet if you would mix things up.
… you know what, the poetry gets too hard for some of the rest,
let’s revert to prose. Body text: serif or sans
A subjective matter.
Serifs are traditional in English,
but sans-serifs are far more popular on computers.
I and many others prefer serif,
and I feel that serif fits my nebulous notions and nicities for the site.
So I’ll start with serif, but let you choose sans if you prefer.
Fonts
By default, it’ll use your chosen serif, sans-serif and monospace.
This is faster, good enough for everyone (browser defaults are reasonable),
and respects your preferences, if you happen to have chosen fonts.
Personally, I set my defaults to
Equity for serif,
Concourse for sans, and
Triplicate for monospace, long ago.
What’s more, I explicitly block pages from choosing their own fonts.
(Firefox: Settings → Fonts → Advanced… → untick Allow pages to choose their own fonts, instead of your selections above.
TODO: write an article about this and related things.)
But if you’re interested in my chosen fonts,
you can try them out.
Theme
Mere dark modes are so passé.
Auto, Light and Dark? Everyone’s got that.
With me, you can choose how dark, and interpolate between light and dark.
The interpolation is in places very complex; an article is on the way.
I always intended to support more than two themes eventually,
and while implementing the site I discovered an Opportunity.
Graded darkness.
The fullness of this feature requires JavaScript,
because there’s no way to get the value of a range input in CSS,
so I have to set a custom property on the root, --d:0.
But without JavaScript, I’ve provided five presets which you can choose from.
Dev mode
Normal people don’t care about the internals of a website.
It’s good to give them optimised bundles.
Less to download, faster to load, even lower memory usage.
But it’s a shame to limit everyone to this.
One of the great things about the web is that you can inspect everything.
(Some things in this way are better than they used to be—especially dev tools—
but overall I think it’s probably worse.)
So, turn on dev mode, which sets a cookie dev=1,
and the server will provide unminified/unoptimised pages.
Then you can view-source: everything and it’ll be much easier to read.
The markup will be largely as I wrote it. Caddy implementation
(I’ll move this to a separate page soon.) Here’s how I implement it:
map {http.request.cookie.dev} {pages_dir} {
1 pages
default pages.min
}
try_files {pages_dir}/{path}.html …
That is: it’ll serve files in pages.min/ by default,
but if there’s a cookie dev=1,
it’ll serve files in pages/ instead.
In reality it’s a bit more complex because I also want to set checked attributes on the correct radio buttons/checkboxes without needing JS.
What the difference is in non-dev builds
At present, it’s more a proof of concept.
Bit of a nuisance, actually—I’ve found a few problems with my chosen tool,
so I don’t quite trust it not to damage things.
But I’ve committed to the concept, so I’ll live with it and try to avoid problems.
Also, j9t has been fixing most of the bugs I report almost faster than I can report them,
and definitely faster than I can look into fixing them myself.
Each page is fed through html-minifier-next with:
preset “comprehensive”: better defaults for me.
conservativeCollapse true: I use some conditionally-hidden line breaks (e.g. <br class=w>), so I need to keep a space around such elements. (With my authoring practices, preserveLineBreaks true would have worked too, and been subjectively prettier. At some point I may even play around with applying white-space: pre-line more generally instead of using my conditional <br>s.)
continueOnParseError false: I don’t want it to be lax, this is actually helpful.
Also, in at least one case that I found it didn’t behave correctly:
equals sign in unquoted attribute value led to mangulation (largely fixed in 6.1.3/6.1.4).
I think this being included in the comprehensive preset is a mistake.
Note that this is no panacea: it doesn’t detect all parse errors, and may mangle on them.
One mistake in element nesting completely broke one page (haven’t filed yet).
ignoreCustomFragments ["⦃⦃.*?⦄⦄"]:
needed for the Caddy template delimiters, for setting the pref form field state.
The particular choice is a bit of fun; I looked through all the Unicode brackets and chose.
I only need this because I’m doing crazy stuff while insisting on supporting no-JS as far as possible.
collapseAttributeWhitespace false: I commonly use significant whitespace in the title attribute, and it will ruin that.
This may incidentally improve CSS compatibility,
since it runs Lightning CSS over it.
I haven’t yet fiddled with that to optimise for it.
In the future I plan to do a lot more.
Integrating something similar to UnCSS to only include the CSS each page uses.
I’m not impressed with the state of much of this kind of thing.
I’ll probably write a bunch of stupid fiddly stuff, in public,
to perhaps inspire people about how much better things could be.