8709bf9ec2
Use a new branch of webmentiond that lets me pull in all webmentions for all pages in a single JSON response Before, Hugo would make one request to webmentiond per page to ask for approved webmentions for that page. Sometimes, it makes two requests because some pages used to have a different canonical location. In all, it ended up making over 150 requests within a second or two. Webmentiond can handle this for now, but this isn't sustainable: page count will only increase with time. I wanted to have Hugo instead get all webmentions for all pages in one cached request. I recompiled webmentiond from https://github.com/zerok/webmentiond/pull/65, which updates the API to support admin access keys. The admin API allows pulling in all webmentions for all pages, instead of pulling them in for one page at a time. Doing so requires getting a bearer token, so I had to manage a new CI secret: the password for getting a token. I get the token in a shell script (get-token.sh) and write it to a temporary file, then have Hugo read the token from that file. The shell script gets the password using either the CI secret (in CI) or using my password manager (on my workstation). TODO: support marginalia (mentions with fragments in their targets) |
||
|---|---|---|
| archetypes | ||
| assets | ||
| content | ||
| csv | ||
| dynamic | ||
| layouts | ||
| linter-configs | ||
| scripts | ||
| static | ||
| .achecker.yml | ||
| .build.yml | ||
| .gitignore | ||
| .rsyncignore | ||
| config.toml | ||
| LICENSE | ||
| Makefile | ||
| Makefile.online | ||
| package.json | ||
| README.md | ||
seirdy.one
Code for my personal website, seirdy.one. Built with Hugo.
Also builds my Gemini capsule: gemini://seirdy.one/.
Dependencies
To build:
- Hugo 0.93 or later
- bmake or GNU Make. OpenBSD make (omake) should work too, but I haven't tested it.
- Git (Hugo uses Git info for features like date last updated)
- htmlq, to parse HTML when fetching some webring links and for some post-processing.
- POSIX utils:
grep,find, POSIX-compliant/bin/sh, etc.
Before deploying, I use some tools to process the output.
xmllint, part of libxml2, to format the generated polygot XHTML5 markup.- sd (for advanced multi-line regex operations, much of which exist to fix
xmllint's output)
I also apply static compression at max levels, using the following tools:
- Efficient Compression Tool It's like zopfli but more efficient and faster.
- Brotli
To deploy:
- rsync, with SSH and zstd support
To lint:
- stylelint, invoked using pnpm.
- lychee, to check broken links.
- A very recent build of the w3c's Nu HTML checker to validate the HTML and XHTML.
- jq, to filter false-positives from the Nu HTML checker.
Build instructions
- To just build the HTML:
make hugo - To build the polygot formatted HTML and XHTML:
make hugo xhtmlize - To lint and validate:
make hugo xhtmlize lint-local - To build everything and compress:
make hugo xhtmlize compress - To deploy the clearnet site and corresponding Tor hidden service:
make deploy-prod deploy-onion
make can parallelize only a little, since many jobs depend on previous jobs.
Compatibility
I made the site as inclusive as possible. Tested using multiple screen readers (Orca, TalkBack, Apple VoiceOver, Windows Narrator, NVDA), and I regularly test with the following browsers/engines. Testing in a browser does not imply any sort of endorsement; I just want to meet people where they're at and I want my site to be as robust as possible.
For all the listed options, I test "reading mode" whenever it's available. Most of my testing happens on Linux since that's my main OS, but I sometimes test on a Windows machine.
The main compatibility issue is a lack of support for <details>; the only non-mainstream engine to support it is Servo. The site is still perfectly usable without support for <details>; users will just be annoyed by pre-expanded toggle buttons that don't do anything.
Desktop
Mainstream engines:
- Gecko: Nightly, Stable, ESR, and sometimes Pale Moon
- the Tor Browser
- Blink: latest Chromium snapshot, stable, and QtWebEngine
- WebKit, via Webkit2GTK3
Non-mainstream engines:
- NetSurf
- The SerenityOS Browser (does not yet support ECDSA-based certs, so I test on my Tildeverse mirror). Known issue: SVG avatar doesn't render unless I view it in a new tab.
- Very old WebKit via rekonq (Qt4 QtWebKit).
- KHTML (KF5), via Konqueror.
- Servo
- Tkhtml, via Hv3 (no TLS 1.2, so I use a terminating proxy or localhost version)
Tested on a provisional basis, when I have access to a Windows machine:
- Winternight Classic.
- IE 11.
- Even older WebKit, via Safari 5.1.7. Requires a TLS terminating proxy.
- Ancient Gecko, via NetScape Navigator. Requires a TLS terminating proxy.
Desktop screen readers tested:
- Orca
- NVDA
- Windows Narrator
- TODO: borrow someone's mac and test macOS VoiceOver.
Mobile
- Android: Blink, Gecko, Tor Browser
- iOS WebKit: latest stable version, iOS 12, iOS 10 on an iPhone 5. Also tested Reader Mode.
- TODO: try a KaiOS device and Samsung Internet's dark mode.
The site should work well even on viewports that are under 240 CSS pixels wide.
Mobile screen readers:
- TalkBack
- VoiceOver
- TODO: test KaiOS Readout
Smart watches
- Borrowed an Apple Watch to try the embedded browser.
- TODO: test on a Tizen or Wear OS device's browser (Samsung Internet is a popular choice)
Accessibility
To my knowledge, this site meets all applicable WCAG 2.2 AA requirements.
This site meets all applicable WCAG 2.2 AAA requirements, with the following exceptions:
- SC 1.4.8 Visual Presentation: long article body text for articles should have an average character count per line below 80 characters. Some lines may exceed this limit. Text outside of article bodies has a longer line width.
- SC 2.4.9 Link Purpose (Link Only): I mostly follow this guideline, but there may be some exceptions. Link purpose in context is always clear, though.
- SC 3.1.5 Reading Level: the required reading ability often exceeds the lower secondary education level
- SC 3.1.6 Pronunciation: I do not yet provide pronunciation information.
I have only tested WCAG compliance in mainstream browser engines (Blink, Gecko, WebKit).
I also go further than WCAG in many aspects.
- Rather than follow SC 2.5.5's requirement to achieve a minimum tap target size of 44 by 44 pixels, I follow Google's more strict guidelines. These guidelines mandate that targets are at least 48-by-48 pixels, with no overlap against any other targets in a 56-by-56 pixel range.
- I ensure at least one such 56-by-56 pixel non-interactive region exists on the page, for users with hand tremors or or anyone who wants to tap the screen without clicking something.
- I only set custom colors in response to the
prefers-color-scheme: darkmedia query. These custom colors pass APCA contrast ratios, all being close to the ideal lightness contrast of 90. They are also autism- and overstimulation-friendly colors: yellow links are significantly de-saturated to reduce harshness.