Stylistic fixes (minor)

Nothing new, just re-phrasing and capitalization.

content/posts/website-best-practices.gmi

@@ -7,7 +7,7 @@ This is a "living document" that I add to as I receive feedback.
 I realize not everybody's going to ditch the Web and switch to Gemini or Gopher today (that'll take, like, a month at the longest). Until that happens, here's a non-exhaustive, highly-opinionated list of best practices for websites that focus primarily on text:
 
 * Final page weight under 50kb without images, and under 200kb with images. Page weight should usually be much smaller; these are upper-bounds for exceptional cases.
-* Works in Lynx, w3m, links (both graphics and text mode), Netsurf, and Dillo
+* Works in Lynx, w3m, links (both graphics and text mode), NetSurf, and Dillo
 * Works with popular article-extractors (e.g. Readability) and HTML-to-Markdown converters. This is a good way to verify that your site uses simple HTML and works with most non-browser article readers (e.g. ebook converters, PDF exports).
 * No scripts or interactivity (preferably enforced at the CSP level)
 * No cookies
@@ -19,12 +19,12 @@ I realize not everybody's going to ditch the Web and switch to Gemini or Gopher
 * No lazy loading (more on this below)
 * No custom colors OR explicitly set the both foreground and background colors. More on this below.
 * A maximum line length for readability
-* Server configured to support compression (gzip, optionally Brotli and zstd as well). It's a free speed boost.
+* Server configured to support compression (gzip, optionally Brotli and Zstandard as well). It's a free speed boost.
 * Supports dark mode via a CSS media feature and/or works with most "dark mode" browser addons. More on this below.
 * A good score on Mozilla's HTTP Observatory. A bare minimum would be 50, but it shouldn't be too hard to hit 100.
 * Optimized images. More on image optimization below.
 * All images labeled with alt-text. The page should make sense without images.
-* Maybe HTTP/2. There are some cases in which HTTP/2 can make things slower. Run some tests to find out.
+- Probably HTTP/2. There are some edge cases in which HTTP/2 can make things slower. Run some tests to find out.
 
 => https://observatory.mozilla.org/ HTTP Observatory
 
@@ -36,7 +36,7 @@ Earlier revisions of this post generated some responses I thought I should addre
 
 If you really want, you could use serif instead of sans-serif; however, serif fonts tend to look worse on low-res monitors. Not every screen's DPI has three digits.
 
-To ship custom fonts is to assert that branding is more important than user choice. That might very well be a reasonable thing to do; branding isn't evil! It isn't *usually* the case for textual websites, though. Beyond basic layout and optionally supporting dark mode, authors generally shouldn't dictate the presentation of their websites; that should be the job of the user agent. Most websites are not important enough to look completely different from the rest of the user's system.
+To ship custom fonts is to assert that branding is more important than user choice. That might very well be a reasonable thing to do; branding isn't evil! That being said, textual websites in particular don't benefit much from branding. Beyond basic layout and optionally supporting dark mode, authors generally shouldn't dictate the presentation of their websites; that should be the job of the user agent. Most websites are not important enough to look completely different from the rest of the user's system.
 
 A personal example: I set my preferred fonts in my computer's fontconfig settings. Now every website that uses sans-serif will have my preferred font. Sites with sans-serif blend into the users' systems instead of sticking out.
 
@@ -52,15 +52,15 @@ That being said, many users *do* actually override stylesheets. We shouldn't *re
 
 ### But wouldn't that allow a website to fingerprint with fonts?
 
-I don't know much about fingerprinting, except that you can't do font enumeration without JavaScript. Since text-based websites that follow these best-practices don't send requests after the page loads and have no scripts, fingerprinting via font enumeration is a non-issue on those sites.
+I don't know much about fingerprinting, except that you can't do font enumeration without JavaScript. Since text-based websites that follow these best-practices don't send requests after the page loads and have no scripts, they shouldn't be able to fingerprint via font enumeration.
 
-Other websites can still fingerprint via font enumeration using JavaScript. They don't need to stop at seeing what sans-serif maps to; they can see all the available fonts on a user's system, the user's canvas fingerprint, window dimensions, etc. Some of these can be mitigated with Firefox's "privacy.resistFingerprinting" setting, but that setting also understandably overrides user font preferences.
+Other websites can still fingerprint via font enumeration using JavaScript. They don't need to stop at seeing what sans-serif maps to: they can see all the available fonts on a user's system, the user's canvas fingerprint, window dimensions, etc. Some of these can be mitigated with Firefox's "privacy.resistFingerprinting" setting, but that setting also understandably overrides user font preferences.
 
 Ultimately, surveillance self-defense on the web is an arms race full of trade-offs. If you want both privacy and customizability, the web is not the place to look; try Gemini or Gopher instead.
 
 ## About lazy loading
 
-For users on slow connections, lazy loading is often frustrating. I think I can speak for some of these users: mobile data near my home has a number of "dead zones" with abysmal download speeds, and my home's Wi-Fi repeater setup occasionally results in packet loss rates above 60% (!!).
+Lazy loading often frustrates users on slow connections. I think I can speak for some of these users: mobile data near my home has a number of "dead zones" with abysmal download speeds, and my home's Wi-Fi repeater setup occasionally results in packet loss rates above 60% (!!).
 
 Users on poor connections have better things to do than idly wait for pages to load. They might open multiple links in background tabs to wait for them all to load at once, or switch to another window/app and come back when loading finishes. They might also open links while on a good connection before switching to a poor connection. For example, I often open 10-20 links on Wi-Fi before going out for a walk in a mobile-data dead-zone. A Reddit user reading an earlier version of this article described a similar experience when travelling by train:
 
@@ -131,7 +131,7 @@ It might seem odd to create a lossless WebP from a lossy PNG, but I've found tha
 
 In general, avoid using inline images just for decoration. Only use an image if it significantly adds to your content, and provide alt-text as a fallback.
 
-If you want to include a profile photo (e.g., if your website is part of the IndieWeb), I recommend re-using one of your favicons. Since most browsers will fetch your favicons anyway, re-using them should be relatively harmless.
+If you want to include a profile photo (e.g., if your website is part of the IndieWeb), I recommend re-using one of your favicons. Doing so should be harmless since most browsers will fetch and cache favicons anyway.
 
 ## Layout
 

content/posts/website-best-practices.md

@@ -18,7 +18,7 @@ This is a "living document" that I add to as I receive feedback. See the [change
 I realize not everybody's going to ditch the Web and switch to Gemini or Gopher today (that'll take, like, a month at the longest). Until that happens, here's a non-exhaustive, highly-opinionated list of best practices for websites that focus primarily on text:
 
 - Final page weight under 50kb without images, and under 200kb with images. Page weight should usually be much smaller; these are upper-bounds for exceptional cases.
-- Works in Lynx, w3m, links (both graphics and text mode), Netsurf, and Dillo
+- Works in Lynx, w3m, links (both graphics and text mode), NetSurf, and Dillo
 - Works with popular article-extractors (e.g. Readability) and HTML-to-Markdown converters. This is a good way to verify that your site uses simple HTML and works with most non-browser article readers (e.g. ebook converters, PDF exports).
 - No scripts or interactivity (preferably enforced at the CSP level)
 - No cookies
@@ -30,12 +30,12 @@ I realize not everybody's going to ditch the Web and switch to Gemini or Gopher
 - No lazy loading (more on this below)
 - No custom colors OR explicitly set the both foreground and background colors. More on this below.
 - A maximum line length for readability
-- Server configured to support compression (gzip, optionally Brotli and zstd as well). It's a free speed boost.
+- Server configured to support compression (gzip, optionally Brotli and Zstandard as well). It's a free speed boost.
 - Supports dark mode via a CSS media feature and/or works with most "dark mode" browser addons. More on this below.
 - A good score on Mozilla's [HTTP Observatory](https://observatory.mozilla.org/). A bare minimum would be 50, but it shouldn't be too hard to hit 100.
 - Optimized images. More on image optimization below.
 - All images labeled with alt-text. The page should make sense without images.
-- Maybe HTTP/2. There are some cases in which HTTP/2 can make things slower. Run some tests to find out.
+- Probably HTTP/2. There are some edge cases in which HTTP/2 can make things slower. Run some tests to find out.
 
 I'd like to re-iterate yet another time that this only applies to websites that primarily focus on text. If graphics, interactivity, etc. are an important part of your website, less (possibly none) of this article applies.
 
@@ -46,7 +46,7 @@ About fonts
 
 If you really want, you could use serif instead of sans-serif; however, serif fonts tend to look worse on low-res monitors. Not every screen's DPI has three digits.
 
-To ship custom fonts is to assert that branding is more important than user choice. That might very well be a reasonable thing to do; branding isn't evil! It isn't _usually_ the case for textual websites, though. Beyond basic layout and optionally supporting dark mode, authors generally shouldn't dictate the presentation of their websites; that should be the job of the user agent. Most websites are not important enough to look completely different from the rest of the user's system.
+To ship custom fonts is to assert that branding is more important than user choice. That might very well be a reasonable thing to do; branding isn't evil! That being said, textual websites in particular don't benefit much from branding. Beyond basic layout and optionally supporting dark mode, authors generally shouldn't dictate the presentation of their websites; that should be the job of the user agent. Most websites are not important enough to look completely different from the rest of the user's system.
 
 A personal example: I set my preferred fonts in my computer's fontconfig settings. Now every website that uses sans-serif will have my preferred font. Sites with sans-serif blend into the users' systems instead of sticking out.
 
@@ -62,16 +62,16 @@ That being said, many users _do_ actually override stylesheets. We shouldn't _re
 
 ### But wouldn't that allow a website to fingerprint with fonts?
 
-I don't know much about fingerprinting, except that you can't do font enumeration without JavaScript. Since text-based websites that follow these best-practices don't send requests after the page loads and have no scripts, fingerprinting via font enumeration is a non-issue on those sites.
+I don't know much about fingerprinting, except that you can't do font enumeration without JavaScript. Since text-based websites that follow these best-practices don't send requests after the page loads and have no scripts, they shouldn't be able to fingerprint via font enumeration.
 
-Other websites can still fingerprint via font enumeration using JavaScript. They don't need to stop at seeing what sans-serif maps to; they can see all the available fonts on a user's system, the user's canvas fingerprint, window dimensions, etc. Some of these can be mitigated with Firefox's `privacy.resistFingerprinting` setting, but that setting also understandably overrides user font preferences.
+Other websites can still fingerprint via font enumeration using JavaScript. They don't need to stop at seeing what sans-serif maps to: they can see all the available fonts on a user's system, the user's canvas fingerprint, window dimensions, etc. Some of these can be mitigated with Firefox's `privacy.resistFingerprinting` setting, but that setting also understandably overrides user font preferences.
 
 Ultimately, surveillance self-defense on the web is an arms race full of trade-offs. If you want both privacy and customizability, the web is not the place to look; try Gemini or Gopher instead.
 
 About lazy loading
 ------------------
 
-For users on slow connections, lazy loading is often frustrating. I think I can speak for some of these users: mobile data near my home has a number of "dead zones" with abysmal download speeds, and my home's Wi-Fi repeater setup occasionally results in packet loss rates above 60% (!!).
+Lazy loading often frustrates users on slow connections. I think I can speak for some of these users: mobile data near my home has a number of "dead zones" with abysmal download speeds, and my home's Wi-Fi repeater setup occasionally results in packet loss rates above 60% (!!).
 
 Users on poor connections have better things to do than idly wait for pages to load. They might open multiple links in background tabs to wait for them all to load at once, or switch to another window/app and come back when loading finishes. They might also open links while on a good connection before switching to a poor connection. For example, I often open 10-20 links on Wi-Fi before going out for a walk in a mobile-data dead-zone. A Reddit user reading an earlier version of this article described a [similar experience](https://i.reddit.com/r/web_design/comments/k0dmpj/an_opinionated_list_of_best_practices_for_textual/gdmxy4u/) riding the train.
 
@@ -130,7 +130,7 @@ It might seem odd to create a lossless WebP from a lossy PNG, but I've found tha
 
 In general, avoid using inline images just for decoration. Only use an image if it significantly adds to your content, and provide alt-text as a fallback.
 
-If you want to include a profile photo (e.g., if your website is part of the IndieWeb), I recommend re-using one of your favicons. Since most browsers will fetch your favicons anyway, re-using them should be relatively harmless.
+If you want to include a profile photo (e.g., if your website is part of the IndieWeb), I recommend re-using one of your favicons. Doing so should be harmless since most browsers will fetch and cache favicons anyway.
 
 Layout
 ------