Use the default font-size

Now that more mobile browsers support text zoom, I don't need to worry
about font size as much. Moreover, iOS and Android support a zoomed mode
that makes all tap targets and text larger. This mode made my site's
larger text uncomfortably larger than other sites. On Android, this is
the "Display size" setting; on iOS, this is the "display zoom" setting
under "Display and Brightness" section.

This commit switches everything back to the browser's default font
sizes to better accomodate non-default zoom levels and display zoom
settings.

assets/css/dark.css

@@ -29,7 +29,7 @@
 	}
 
 	a:visited {
-		color: #ffd8ff;
+		color: #ffd3ff;
 	}
 
 	/* Small text needs higher contrast.

assets/css/main.css

@@ -65,18 +65,6 @@ html {
 /* This should not take effect on printouts, to save paper. */
 @media screen {
 	body {
-		/* Default font sizes are one-size-fits-all; they're optimized for a
-		 * wide variety of complex pages. For single-column websites like
-		 * mine, it's ideal to bump it up ever so slightly. This also makes
-		 * <sup>, <sub>, <small>, etc. large enough to have decent contrast
-		 * with minimal adjustment, and makes tap-targets larger.
-		 * Only do this on screen, since printouts already improve legibility
-		 * and cost paper + ink.
-		 * 109.375% is the minimum required to get text to 17.5 CSS pixels and
-		 * superscripts past 14.75 px with most default stylesheets. At that
-		 * size, my dark color palette has sufficient contrast.*/
-		font-size: 109.375%;
-
 		/* Aligning to the center with space on both sides prevents accidental
 		* link activation on tablets, and is a common practice that users are
 		* more used to for articles. */
@@ -220,6 +208,7 @@ html {
 	/* A11y: If we have a list of disclosure widgets, we need some
 	 * non-interactive space on the screen that's safe to tap. */
 	details,
+	fieldset,
 	form {
 		contain: inline-size layout;
 		margin: .5em 0;
@@ -463,7 +452,6 @@ h1 {
  * precedence over being touch-friendly. */
 @media (max-width: 272px) {
 	body {
-		font-size: 100%;
 		-webkit-hyphens: auto;
 		hyphens: auto;
 		padding: 0 8px;

content/notes/politics-and-37signals.md

@@ -11,7 +11,7 @@ Last year, 37signals employees shared the "pyramid of hate" in a work chat in re
 
 However, I don't think this policy is in effect anymore: 37signals leadership is <del cite="https://dragonscave.space/@miki/109411822474469057">using a company blog for</del> [railing against diversity and inclusion](https://world.hey.com/dhh/the-waning-days-of-dei-s-dominance-9a5b656c), and then [doubling down after criticism](https://world.hey.com/dhh/we-must-say-no-to-these-people-e0fb301c). Is the "no politics" rule lifted, is upper management exempt, or does "no politics" only refer to politics that challenges David Heinemeier Hansson to change his behavior? I look forward to hearing a clarification on this rule.
 
-<ins cite="https://dragonscave.space/@miki/109411822474469057">Update <time>2022-11-26</time>: {{<indieweb-person name="Mikołaj Hołysz" itemprop="mentions" url="https://dragonscave.space/@miki">}} tells me that [this isn't a company blog](https://dragonscave.space/@miki/109411822474469057); however, I do think this likely reflects a current or future political stance from 37signals against diversity, equity, and inclusion.</ins>
+<ins itemprop="correction" itemscope="" itemtype="https://schema.org/CorrectionComment" cite="https://dragonscave.space/@miki/109411822474469057">Update <time itemprop="datePublished">2022-11-26</time>: <span itemprop="text">{{<indieweb-person name="Mikołaj Hołysz" itemprop="mentions" url="https://dragonscave.space/@miki">}} tells me that [this isn't a company blog](https://dragonscave.space/@miki/109411822474469057); however, I do think this likely reflects a current or future political stance from 37signals against diversity, equity, and inclusion.</span></ins>
 
 37signals is known for creating Basecamp, Hey.com (an email service with bespoke email filters that are somehow incompatible with IMAP), and for creating Ruby on Rails. It appears to remain a key member of the Rails Foundation. For now.
 

content/posts/experiment-copilot-legality.gmi

@@ -113,7 +113,7 @@ I don't think that "going after" a smaller player just to manipulate our legal s
 
 ## Corrections
 
-It's come to my attention that Eloquence may or may not still belong to Nuance. Further research is needed.
+Updated on 2022-07-02: It's come to my attention that Eloquence may or may not still belong to Nuance. Further research is needed.
 Eloquent Technology was acquired by SpeechWorks in 2000.
 
 ## Footnotes

content/posts/experiment-copilot-legality.md

@@ -1,6 +1,6 @@
 ---
 title: "An experiment to test GitHub Copilot's legality"
-date: 2022-07-01T17:30:45-07:00
+date: "2022-07-01T17:30:45-07:00"
 description: "A horrible idea to determine the legality of GitHub Copilot, or of re-creating proprietary speech synthesizers: create legal precedent that doesn't exist yet!"
 outputs:
     - html
@@ -136,7 +136,7 @@ I don't think that "going after" a smaller player just to manipulate our legal s
 Corrections
 -----------
 
-It's come to my attention that Eloquence may or may not still belong to Nuance. Further research is needed. Eloquent Technology was acquired by SpeechWorks in 2000.
+<span itemprop="correction" itemscope="" itemtype="https://schema.org/CorrectionComment">Updated on <time itemprop="datePublished">2022-07-02</time>: <span itemprop="text">It's has come to my attention that Eloquence may or may not still belong to Nuance. Further research is needed. Eloquent Technology was acquired by SpeechWorks in 2000.</span></span>
 
 </section>