Style: reduce horizontal scroll, element borders

All pages should now look good on screens 230px wide (DPR=1), inc. most
feature-phones running e.g. KaiOS.

Add borders to images so they look distinct from the surrounding page.

assets/css/dark.css

@@ -7,11 +7,6 @@
 		color: #ececec;
 	}
 
-	/* IndieWeb u-photo shouldn't look like floating punctuation marks */
-	.u-photo {
-		border: 1px solid #ddc;
-	}
-
 	a {
 		color: #ed7;
 	}
@@ -27,6 +22,7 @@
 	blockquote,
 	:not(pre) > code,
 	hr,
+	img,
 	pre {
 		border-color: #333;
 	}

assets/css/main.css

@@ -6,14 +6,19 @@
  *    regular text.
  * 3. max text width for readability
  * 4. single-row nav links widescreen, multiline nav on narrow screens
- * 5. Soft border around code in case it looks too similar to regular
- *    text, and to show it continue across more than one line
+ * 5. Soft border around code and images to disginguish from the
+ *    surrounding page. Images with white/black or transparent
+ *    backgrounds should have clear dimensions, and multiple consecutive
+ *    inline <code> spans should look separate. A <code> span that
+ *    continues across multiple lines should not look like multiple different
+ *    spans.
  * 6. Increase the line-spacing a bit so users on mobile devices can
  *    tap links more easily.
  * 7. Horizontally center non-inline images; left-aligned stick out.
  * 8. dark.css changes a few colors if the browser wants dark mode.
  * 9. Support unstyled lists: for webmentions, post lists, nav links.
- * 10. Make blockquotes look okay on narrow screens.
+ * 10. Narrow screen optimization: less-indented blockquotes, overflow
+ *     behavior for <pre>.
  * Everything else is browser defaults:
  * default fonts, non-dark-mode colors, etc.
  */
@@ -61,6 +66,13 @@ img:not(.u-photo) {
 	max-width: 100%;
 }
 
+/* Distinguish images from the background in case their color is
+ * too similar to the page background color */
+img,
+pre {
+	border: 1px solid #bbb;
+}
+
 code,
 pre {
 	/* browsers make <pre> small for some dumb legacy reason
@@ -72,12 +84,16 @@ pre {
 	/* stylelint-enable */
 }
 
-pre,
 /* don't put a border around code within a <pre> block,
  * just put the border around the <code> */
 :not(pre) > code {
 	border: 1px solid #bbb;
 	padding: 0 0.1em;
+	overflow-wrap: break-word;
+}
+
+li.u-comment.h-cite {
+	overflow-wrap: break-word;
 }
 
 /* Allow horizontal scroll in a pre block, but don't clip it vertically */

content/posts/keeping-platforms-open.md

@@ -1,15 +1,14 @@
 ---
 date: "2021-02-23T11:54:00-08:00"
-description: "How open platforms become closed, and how standards-driven development
-    can prevent it from happening."
+description: "How open platforms become closed, and how standards-driven development can prevent it from happening."
 footnote_heading: "Notes"
 outputs:
-  - html
-  - gemtext
+    - html
+    - gemtext
 tags:
-  - free software
-  - user domestication
-  - platforms
+    - free software
+    - user domestication
+    - platforms
 title: Keeping platforms open
 ---
 This article is the second entry of series of posts exploring situations in which <abbr title="free, libre, and open-source software">FLOSS</abbr> alone isn't enough to secure user freedom.
@@ -124,8 +123,8 @@ The standards- and consensus-driven approach to platform development and the ine
 
 Perhaps the biggest benefit to abandoning the "move fast and break things" mindset is that in addition to making it hard to rapidly improve a service, abandoning the mindset also makes it hard to rapidly worsen a service.
 
-Acknowledgements
-----------------
+Acknowledge&shy;ments
+---------------------
 
 {{<indieweb-person first-name="Denver" last-name="Gingerich" url="https://ossguy.com/">}} helped me brainstorm early in the writing process and provided useful information for the section on XMPP.
 
@@ -144,3 +143,4 @@ Thanks to {{<indieweb-person first-name="Barna" last-name="Zsombor" url="https:/
 
 [^6]: I decided against using the cheeky sub-heading "Scaling considered harmful" because I worried that readers on a certain orange-colored website might take the joke too seriously.
 
+

content/posts/password-strength.md

@@ -239,8 +239,8 @@ One well-known approach to calculating physical limits of computation is [Bremer
 
 [A publication](https://arxiv.org/abs/quant-ph/9908043)[^5] by Seth Lloyd from MIT further explores limits to computation speed on an ideal 1-kilogram computer.
 
-Acknowledgements
-----------------
+Acknowledge­ments
+---------------------
 
 Thanks to [Barna Zsombor](https://bzsombor.web.elte.hu/) and [Ryan Coyler](https://rcolyer.net/) for helping me over IRC with my shaky physics and pointing out the caveats of my approach. u/RisenSteam on Reddit also corrected an incorrect reference to AES-256 encryption by bringing up salts.
 

content/posts/search-engines-with-own-indexes.md

@@ -239,8 +239,8 @@ I didn't try to avoid personalization when testing engines that require account
 
 I avoided "natural language" queries like questions, focusing instead on keyword searches and search operators. I also mostly ignored infoboxes (also known as "instant answers").
 
-Acknowledgements
-----------------
+Acknowledge­ments
+---------------------
 
 Some of this content came from the [Search Engine Map](https://www.searchenginemap.com/) and [Search Engine Party](https://searchengine.party/). A few web directories also proved useful.
 
@@ -267,6 +267,6 @@ Some of this content came from the [Search Engine Map](https://www.searchenginem
 
 [^9]: More information can be found in [this HN subthread](https://news.ycombinator.com/item?id=27593801) and some posts on the Cliqz tech blog ([one](https://0x65.dev/blog/2019-12-06/building-a-search-engine-from-scratch.html), [two](https://0x65.dev/blog/2019-12-10/search-quality-at-cliqz.html)).
 
-[^10]: Some search engines support the `site:` search operator to limit searches to subpages/subdomains of a single site or TLD. `site:.one`, for instance, limits searches to websites with the ".one" TLD.
+[^10]: Some search engines support the `site:` search operator to limit searches to subpages or subdomains of a single site or TLD. `site:.one`, for instance, limits searches to websites with the ".one" TLD.
 
 

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

@@ -145,7 +145,7 @@ Food for thought
 
 Both of the prior two case studies--Mozilla and Signal--are examples of well-meaning organizations unintentionally leaving users vulnerable to user domestication. The former represents a lack of simplicity but the presence of an open platform. The latter represents a closed platform with a higher degree of simplicity. Intent isn't in the picture when examining the three steps and countermeasures to user domestication.
 
-[@paulsnar@mastodon.technology](https://mastodon.technology/@paulsnar) pointed out a potential conflict between simplicity and open platforms:
+[paulsnar](https://mastodon.technology/@paulsnar) pointed out a potential conflict between simplicity and open platforms:
 
 > I feel like there's some tension between simplicity and open platforms; to take Signal, in a way it's simple precisely because it's a de-facto-closed platform, or at least so Moxie has argued. In turn, Matrix is superficially simple, but the protocol is actually (imho) fairly complex exactly because it's an open platform.