Most work for the website proper is done.
Added the Writing category page, thus setting an example for how category pages ought to go.
In my head, I envisioned something closer to a no-arrow list of plain project descriptions (title, status, and a short comment on what it is). Didn't work out that way because (A) there's already a pattern for how pages ought to go (short first line, then the rest of it), (B) the regular arrowed list style worked out fine.
Point (B) is important because it feels valuable to keep the stylesheet small and abstain from introducing specific classes unless work becomes more difficult otherwise. Introducing classes breaks that little requirement I have for how the HTML should look like. For this project – the website itself – it's supposed to be minimal and streamlines: the fewer additional attributes – more than is required for the markup to work – the better.
Adding classes doesn't just mean adding and editing the CSS, or making sure the class is assigned properly, and supporting it down the line: it also means extending the HTML a little with something that needn't be there. It's a minor concern, but one I feel is worth addressing in this instance: it is, after all, my website – a reflection of myself, to a degree.
Still some things to tweak – like separating major projects from minor ones (e.g. episodic ones from short stories) – which sounds like it would, in fact, warrant at least one separate class.
I'd considered using
<ol> for a secondary list element, in vain hopes that it could eliminate the need for
<ul> classes, but this creates more problems than it solves, from the perspective of semanticity and longevity. There's also the
<menu>, which currently renders as an unordered list in most browsers, but it appears as though its purpose is distinct enough to avoid for rendering lists alone.
Some lists appear to need the arrowed layout, while others may be better off without it: like the navigation sidebar project lists, where each element under the category is an item on an "invisible" list. Currently the consideration put forth for where to display arrows for list items is whether the list is in the content section (
<main>) of the page. Using a separate class for an arrowed list may add versatility, but also increase complexity – a lot for me as a developer, but also a little for viewers. It may create a degree of confusion I'd rather avoid.
In other news, I've updated the included Inter font towards subsets, where each subset is a small portion of symbols (common Latin letters, exotic Latin letters, punctuation). Each subset now loads only when the page contains the symbols: e.g. the "symbols" subset for punctuation only loads when non-common non-letters (like
@) are on the page. The goal is to reduce the delay between entering the page and seeing it typeset in Inter (as opposed to fallback fonts).