Better Icons & URIs
If you hadn’t visited the site since Saturday, the first thing you’d notice would undoubtedly be the lack of Rift. As I mentioned last time, I’ve come to accept it wasn’t the right font for the headings. In lieu of a different choice, what you see right now is Dolly, the same typeface as in the body. I won’t necessarily stick with it, but I must say, I’m very pleased with this one.
By the by, did you catch what I did with the link about the headings font? It takes you directly to
the section I’m talking about, because all article subheadings now have permalinks that show up on
hover or focus too. There is a debate over the best
approach. I’ve used
aria-label="Anchor"
. I’m still contemplating how to move the links outside the heading
elements to minimize redundancy—I don’t yet see an obvious solution that doesn’t sacrifice
semantics.
On a related note, external links (such as that last one) are now marked with an icon, as is common
these days. And speaking of icons, I’ve finally excised all inline SVG from my markup. Now
they’re all included via use
so they can be
cached like any other asset while remaining malleable with CSS.
Bringing order to the icons and their paths led me to simplifying permalinks entirely. You can now find my article React is JavaScript at https://shivjm.blog/react-is-javascript/ instead of https://shivjm.blog/posts/react-is-javascript/, which I think we can all agree looks much nicer. And this time I added a redirect (which wouldn’t work at first because I had placed it after my 404 redirect) so that the untold millions of existing links to my content out there won’t break. I added the link checker just in time to spot the few places where I missed updating my own pages.
Meanwhile, collection pages (tag pages, stream pages & series pages) should all have more appropriate titles and descriptions. All entries should look better in your feed reader as well as on social media. Margins are more uniform and the footer is on every page but one. I won’t rob you of the opportunity to discover for yourself which that is.
On comments
In Comments vs. Responsive Images: A Negotiation, I explained how I switched to Netlify’s responsive image solution in preparation for integrating comments, which I had decided I wanted. Well… I don’t know any more.
I keep vacillating between ‘I want comments’ and ‘I don’t see the point of having comments on this site’. If I do want comments, despite my avowed stance against JavaScript-only content, I wonder if it wouldn’t be better to treat comments as optional content and let them depend on JavaScript after all. Would it be so wrong to require JavaScript to view and post comments? If I did that, it would be easy (relatively speaking) to integrate Isso, Talkyard, or Discourse, though I would still have to do the work of hosting them.
We shall see. I don’t feel a pressing need to add them. Perhaps a more permanent answer will become clear in time. Either way, I still have every intention of supporting Webmentions.
An archival strategy
From the beginning, I’ve wanted to implement automatic archival of the website on each deploy. When I looked into it today, I realized that that article’s solution relies entirely on the author’s code to submit single URIs at a time. I neither want to depend on a third party nor want to submit a solitary URI, so I intend to adapt archivenow to save every URI in my sitemap. All it’s doing is accessing an archive.org URI using a headless browser so that the assets are saved as well.
Once archiving my own content is implemented, I’d like to perform the same process on all the external links on my site, in preparation for the day when they inevitably stop working. (This blog will doubtless last until the sun goes dim. I must be prepared.)
Miscellany
- I added custom processing for the term ‘sic’, because that’s who I am as a person. See if you can spot it in action.
- I
stoleborrowed GitLab’s styles for thekbd
element. - I tried to add a dark mode stylesheet. I really tried. But it was hard enough devising the colour scheme you see. I need time and energy to find a second scheme for dark mode, especially considering I never use it. (Remind me to rant about it someday.)
- Dates look nicer.
- The line at the end of an article about its position in the series also has some special handling.
- Inline code (like
<code>
) better matches the size of the rest of the text. - Regular text is now a proper shade of black instead of a very dark purple.
- External assets use Subresource Integrity where possible to keep malicious actors from tampering with… the colours, I suppose (though I may welcome said actors if they can come up with a dark mode scheme). I added caching to posthtml-sri so this wouldn’t slow down my deploys to a crawl.
- The email address works at last!