New note: XML adventures

I don't think it's necessary. One less declaration.

assets/css/main.css

@@ -83,10 +83,6 @@ html {
 	}
 
 	summary {
-		/* The tappable region of a <summary> extends across the page.
-		 * we need to tell users that the full space is interactive.
-		 * Use a border for that. */
-		border: 1px solid #999;
 		/* It's not obvious that a <summary> has button semantics.
 		 * "cursor: pointer" is used on MDN, web.dev, GitHub, gov.uk, and
 		 * others so it's not "novel" and won't surprise users. */
@@ -317,10 +313,13 @@ pre {
 /* Distinguish images from the background in case their color is
  * too similar to the page background color. Also put a border around
  * <pre> and <code> to distinguish them in ways besides font-family.
+ * The tappable region of a <summary> extends across the page: we
+ * need to tell users that the full space is interactive.
  * This is Technique C25 of SC 1.4.8 */
 input,
 img,
-pre {
+pre,
+summary {
 	border: 1px solid;
 }
 

content/notes/minimal-website-responsiveness.md

@@ -0,0 +1,25 @@
+---
+title: "Minimal website responsiveness"
+date: 2022-06-11T13:00:26-07:00
+replyURI: "https://social.treehouse.systems/@ayushnix/108460135741971671"
+replyTitle: "Can anyone explain why someone would want to scale font size using multiple media query breakpoints using different device widths or by using fluid typography?"
+replyType: "SocialMediaPosting"
+replyAuthor: "Ayush Agarwal"
+replyAuthorURI: "https://microblog.ayushnix.com/"
+---
+My current approach to "responsiveness" is to increase the font sizes on screens. User interfaces should generally have smaller text while article bodies should prioritize readability and be larger. Default stylesheets are take a (literal) one-size-fits-all approach, trying to optimize for both. But I only use percentages for font sizes, to respect user preferences.
+
+I also increase the default font size to make it easier to increase tap target sizes to Google's recommended 48x48 px sizes, without overlapping other targets in a 56x56 px radius. A size of 108.75% was the minimum necessary to achieve my goals in all combinations of major browsers and their default stylesheets across operating systems. Since scrollbars and screen edges are often tap targets, I also set minimum margin sizes.
+
+I reduce the font size to the default 100% and eliminate the extra margins on extremely narrow screens (think KaiOS devices and smartwatches) where the screen is too small to fit several touch-friendly elements. I do the same on print.
+
+My rationale:
+
+- If you use a smart feature phone, then you navigate with a keypad. The interface does not need to be touch-friendly.
+
+- If you use a smartwatch (like the Apple Watch) it should auto enable reading mode for long-form text, so compromising a _little_ on readability might be worth improving navigation.
+
+- If you want to read in a sidebar then you are likely reading the article alongside some other text. My page's text should match most other content instead of "sticking out".
+
+- If you print it out then font sizes are already optimized for readability rather than for user interfaces.
+

content/notes/tuis-and-accessibility.md

@@ -0,0 +1,14 @@
+---
+title: "TUIs and accessibility"
+date: 2022-06-11T13:13:15-07:00
+replyURI: "https://floss.social/@alcinnz/108460252689906224"
+replyTitle: 'My understanding so far has been limited to "use Gettext…avoid NCurses"'
+replyType: "SocialMediaPosting"
+replyAuthor: "Adrian Cochrane"
+replyAuthorURI: "https://adrian.geek.nz/"
+---
+ncurses is fine for certain specific purposes, like querying terminal characteristics.
+
+I think if you're building a <abbr title="textual user interface">TUI</abbr> it should generally be one of multiple options that share a library/backend or it should be something with many alternatives that are at least equivalent, given the poor accessibility of TUIs in general. If one of those things is true, then it should be fine to use ncurses for the TUI.
+
+There's a [Python library called "Textualize"](https://www.textualize.io/) for building TUIs and CLI shells. They're working on a web target which [they claim can get much better accessibility.](https://news.ycombinator.com/item?id=31151158)

content/notes/xml-adventures.md

@@ -0,0 +1,16 @@
+---
+title: "XML adventures"
+date: 2022-06-11T14:59:13-07:00
+replyURI: "https://mk.nixnet.social/notes/91dz17okx7"
+replyTitle: "Take a look at the xml:space attribute if you haven't"
+replyType: "SocialMediaPosting"
+replyAuthor: "Alexandra"
+replyAuthorURI: "https://www.alm.website/me"
+---
+`xml:space` would make whitespace issues easier to handle and simplify [my current solution](https://git.sr.ht/~seirdy/seirdy.one/tree/master/item/scripts/xhtmlize-single-file.sh), but not everything supports XML namespaces; I want to keep this polygot HTML5 and XHTML5 markup for now.
+
+Eventually I’ll offer certain enhancements to the XHTML version (add `index.xhtml` to the URLs or remove `text/html` form your `Accept` header but include `application/xhtml+xml`) and I’ve already made my Atom feeds a bit simpler, but there’s a lot to do before then.
+
+I’ve added ActivityStreams, OStatus, and friends to my Atom feeds; maybe I could add them to my XHTML pages using namespaces, if RDFa doesn’t work out. First I wanna try my hand at writing an ontology for webrings so people can mark up their webrings with RDFa/microdata. That’ll make it easy to do things like check for broken webrings or build cool visualizations of overlapping rings.
+
+I should also try my hand at XSLT for the Atom feeds to get a baseline browser preview.

content/posts/cli-best-practices.md

@@ -163,9 +163,15 @@ References and further reading
 ------------------------------
 
 <ol>
-<li><p>{{<mention-work itemprop="citation" role="doc-credit" itemtype="ScholarlyArticle">}}Harini Sampath, Alice Merrick, and Andrew Macvean. 2021. _{{<cited-work url="https://dl.acm.org/doi/fullHtml/10.1145/3411764.3445544" name="Accessibility of Command Line Interfaces" extraName="headline">}}. In CHI Conference on Human Factors in Computing Systems (CHI '21), May 8–13, 2021, Yokohama, Japan._ ACM, New York, NY, USA 10 Pages. <https://doi.org/10.1145/3411764.3445544>{{</mention-work>}}</p></li>
+<li>
-<li><p>{{<mention-work itemprop="citation" role="doc-credit" itemtype="TechArticle">}}{{<cited-work url="https://www.w3.org/WAI/WCAG22/Techniques/#text" name="Techniques for WCAG 2.2" extraName="headline">}}. Alastair Campbell, Michael Cooper, Andrew Kirkpatrick. W3C. <time datetime="2022-05-30">2022-05-30</time>.{{</mention-work>}}</p></li>
+{{<mention-work itemprop="citation" role="doc-credit" itemtype="ScholarlyArticle" p="true">}}Harini Sampath, Alice Merrick, and Andrew Macvean. 2021. _{{<cited-work url="https://dl.acm.org/doi/fullHtml/10.1145/3411764.3445544" name="Accessibility of Command Line Interfaces" extraName="headline">}}. In CHI Conference on Human Factors in Computing Systems (CHI '21), May 8–13, 2021, Yokohama, Japan._ ACM, New York, NY, USA 10 Pages. <a href="https://doi.org/10.1145/3411764.3445544">DOI 10.1145/3411764.3445544</a>{{</mention-work>}}
-<li><p>{{<mention-work itemprop="citation" role="doc-credit" itemtype="Book">}}{{<cited-work url="https://clig.dev/" name="Command Line Interface Guidelines">}}. Aanand Prasad, Ben Firshman, Carl Tashian, Eva Parish. Commit `89d755c`, <time datetime="2022-04-19">2022-04-19</time>.{{</mention-work>}}</p></li>
+</li>
+<li>
+{{<mention-work itemprop="citation" role="doc-credit" itemtype="TechArticle" p="true">}}{{<cited-work url="https://www.w3.org/WAI/WCAG22/Techniques/#text" name="Techniques for WCAG 2.2" extraName="headline">}}. Alastair Campbell, Michael Cooper, Andrew Kirkpatrick. W3C. <time datetime="2022-05-30">2022-05-30</time>.{{</mention-work>}}
+</li>
+<li>
+{{<mention-work itemprop="citation" role="doc-credit" itemtype="Book" p="true">}}{{<cited-work url="https://clig.dev/" name="Command Line Interface Guidelines">}}. Aanand Prasad, Ben Firshman, Carl Tashian, Eva Parish. Commit `89d755c`, <time datetime="2022-04-19">2022-04-19</time>.{{</mention-work>}}
+</li>
 </ol>
 
 </section>

content/posts/whatsapp-and-the-domestication-of-users.gmi

@@ -192,25 +192,23 @@ Since 2900 words wasn't quite enough, I wrote a follow-up; check it out if you f
 Translations are always welcome
 
 Evgeny Kuznetsov wrote a Russian translation of this article:
-
 => https://evgenykuznetsov.org/posts/2021/domestication/ WhatsApp и одомашнивание пользователей
 
 The Framalang translators at Framasoft translated this article to French:
-
 => https://framablog.org/2021/02/04/utilisateurs-libres-ou-domestiques-whatsapp-et-les-autres/ WhatsApp et la domestication des utilisateurs.
 
 Licaon_Kter translated this article to Romanian:
-
 => https://web.archive.org/web/20210924154306/convorb.im/post/2021/02/14/whatsapp-si-domesticirea-utilizatorilor.html WhatsApp și domesticirea utilizatorilor
 
 David Jimenez translated this article to Spanish:
-
 => gemini://dvejmz.srht.site/whatsapp-y-la-domesticacion-de-usuarios.gmi WhatsApp y la domesticación de usuarios
 
 Andrea of Le Alternative translated this article to Italian:
-
 => https://www.lealternative.net/2021/12/13/whatsapp-e-laddomesticamento-degli-utenti/ WhatsApp e l’addomesticamento degli utenti
 
+puer robustus translated this article to German:
+=> https://www.puer-robustus.eu/2022/06/10/domestizierung-von-nutzern.html WhatsApp und die Domestizierung von Nutzern
+
 ## References and Endnotes
 
 ¹ Pierotti, R.; Fogg, B. (2017). The First Domestication: How Wolves and Humans Coevolved. Yale University Press.

content/posts/whatsapp-and-the-domestication-of-users.md

@@ -226,6 +226,8 @@ Translations are always welcome.
 
 - {{<mention-work itemprop="workTranslation" itemtype="BlogPosting">}}{{<indieweb-person itemprop="author" nickname="Skariko" url="https://www.lealternative.net/author/skariko/" org="Le Alternative" org-url="https://lealternative.net/">}} translated this article to <span itemprop="inLanguage">Italian</span>: {{<cited-work lang="it-IT" rel="alternate" url="https://www.lealternative.net/2021/12/13/whatsapp-e-laddomesticamento-degli-utenti/" name="WhatsApp e l’addomesticamento degli utent">}}{{</mention-work>}}.
 
+- {{<mention-work itemprop="workTranslation" itemtype="BlogPosting">}}{{<indieweb-person itemprop="author" nickname="puer robustus" url="https://www.puer-robustus.eu">}} translated this article to <span itemprop="inLanguage">German</span>: {{<cited-work lang="de-DE" rel="alternate" url="https://www.puer-robustus.eu/2022/06/10/domestizierung-von-nutzern.html" name="WhatsApp und die Domestizierung von Nutzern">}}{{</mention-work>}}.
+
 
 [^1]: <span itemprop="citation">Pierotti, R.; Fogg, B. (2017). The First Domestication: How Wolves and Humans Coevolved. Yale University Press.</span>
 

content/site-design.md

@@ -45,7 +45,7 @@ I also go further than WCAG in many aspects:
 
 - I ensure at least one such 56-by-56 px 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: dark` media 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.
+- With the exception of in-text borders, I only set custom colors in response to the `prefers-color-scheme: dark` media 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.
 
 - I ensure that the page works on extremely narrow viewports without triggering two-dimensional scaling. It should work at widths well below 200 CSS pixels.
 
@@ -55,7 +55,15 @@ I test each WCAG success criterion myself using the mainstream browser engines (
 
 I also accept user feedback. Users are free to contact me through any means linked on my [About page](../about/).
 
-Finally, I supplement manual testing with automated tools. I run [axe-core](https://github.com/dequelabs/axe-core), the [IBM Equal Access Accessibility Checker](https://www.ibm.com/able/toolkit/verify/automated), [AInspector](https://github.com/ainspector/ainspector-for-firefox), the [WAVE Web Accessibility Evaluation Tool](https://wave.webaim.org/), and [ARC Toolkit](https://www.tpgi.com/arc-platform/arc-toolkit/). WAVE reports no errors; AXE is unable to determine certain contrast errors, but it otherwise reports no errors; IBM Equal Access reports no errors but some items that need review.
+Finally, I supplement manual testing with the following automated tools:
+
+- [axe-core](https://github.com/dequelabs/axe-core)
+- [IBM Equal Access Accessibility Checker](https://www.ibm.com/able/toolkit/verify/automated)
+- [AInspector](https://github.com/ainspector/ainspector-for-firefox)
+- [WAVE Web Accessibility Evaluation Tool](https://wave.webaim.org/)
+- [ARC Toolkit](https://www.tpgi.com/arc-platform/arc-toolkit/)
+
+WAVE reports no errors; AXE is unable to determine certain contrast errors, but it otherwise reports no errors; IBM Equal Access reports no errors but some items that need review.
 
 Browser engine compatibility
 ----------------------------
@@ -89,7 +97,7 @@ The aforementioned metadata (microdata, microformats) has improved reading-mode
 
 This site should fully support the Readability algorithm. The Readability algorithm is used by Firefox and Vivaldi. It's the basis of one of multiple distillers used by Brave; Brave typically uses its Readability-based logic on seirdy.one. Readability is the only article distillation algorithm I try to actively support.
 
-This site happens to fully supports Apple's Reader Mode and Azure Immersive Reader (AIR), the latter of which powers Microsoft Edge's reading mode. Unfortunately, AIR applies a stylesheet atop the extracted article that makes figures difficult to read: it centers text in figures, included pre-formatted blocks. I filed an issue on AIR's feedback forum, but that forum was subsequently deleted.
+This site happens to fully support Apple's Reader Mode and Azure Immersive Reader (AIR), the latter of which powers Microsoft Edge's reading mode. Unfortunately, AIR applies a stylesheet atop the extracted article that makes figures difficult to read: it centers text in figures, included pre-formatted blocks. I filed an issue on AIR's feedback forum, but that forum was subsequently deleted.
 
 This site works well in the Diffbot article extractor. Diffbot powers a variety of services, including Instapaper.
 

layouts/partials/processed-content.html

@@ -63,4 +63,4 @@
 {{- $extraLanguageFigure := `<pre><(code|samp) class="language-figure">` -}}
 {{- $replacedLanguageFigure := `<pre tabindex="0"><${1} translate="no" itemprop="text">` -}}
 
-{{- .Content | replaceRE $referencesWithoutHeading $referencesWithHeading | replaceRE $badNoteRef $goodNoteRef | replaceRE $endnotesClosingDiv $endnotesClosingSection | replaceRE $combinedTerm $splitTerm | replaceRE $tocHeadingOutside $tocHeadingInside | replaceRE $footnoteBacklinksBad $footnoteBacklinksGood | replaceRE $repeatedFootnoteBacklinksBad $repeatedFootnoteBacklinksGood | replaceRE $endNotesNotFocusable $endNotesFocusable | replaceRE $extraLanguageFigure $replacedLanguageFigure | replaceRE `\&rsquo;` `’` | replaceRE `\&nbsp;` `&#160;` | replaceRE `\&ldquo;` `“` | replaceRE `\&rdquo;` `”` | replaceRE `\&hellip;` `—` | replaceRE `\&mdash;` `—` | replaceRE `\&shy;` `&#173;` | replaceRE `&lsquo;` `‘`| safeHTML -}}
+{{- .Content | replaceRE $referencesWithoutHeading $referencesWithHeading | replaceRE $badNoteRef $goodNoteRef | replaceRE $endnotesClosingDiv $endnotesClosingSection | replaceRE $combinedTerm $splitTerm | replaceRE $tocHeadingOutside $tocHeadingInside | replaceRE $footnoteBacklinksBad $footnoteBacklinksGood | replaceRE $repeatedFootnoteBacklinksBad $repeatedFootnoteBacklinksGood | replaceRE $endNotesNotFocusable $endNotesFocusable | replaceRE $extraLanguageFigure $replacedLanguageFigure | replaceRE `\&rsquo;` `’` | replaceRE `\&nbsp;` `&#160;` | replaceRE `\&ldquo;` `“` | replaceRE `\&rdquo;` `”` | replaceRE `\&hellip;` `…` | replaceRE `\&mdash;` `—` | replaceRE `\&shy;` `&#173;` | replaceRE `&lsquo;` `‘`| safeHTML -}}

layouts/shortcodes/mention-work.html

@@ -2,7 +2,14 @@
 {{- with .Get "itemprop" -}}
 	{{ $itemprop = . }}
 {{- end -}}
+{{- if .Get "p" -}}
+<p
+	class="h-cite{{ with .Get "reply" }} in-reply-to{{ end }}" itemprop="{{ $itemprop }}"{{ with .Get "role" }} role="{{ . }}"{{ end }} itemscope="" itemtype="https://schema.org/{{ .Get "itemtype" }}">
+	{{- .Inner | markdownify | safeHTML -}}
+</p>
+{{- else -}}
 <span
 	class="h-cite{{ with .Get "reply" }} in-reply-to{{ end }}" itemprop="{{ $itemprop }}"{{ with .Get "role" }} role="{{ . }}"{{ end }} itemscope="" itemtype="https://schema.org/{{ .Get "itemtype" }}">
 	{{- .Inner | markdownify | safeHTML -}}
 </span>
+{{- end -}}