diff --git a/assets/css/main.css b/assets/css/main.css
index 93097a2..6c59953 100644
--- a/assets/css/main.css
+++ b/assets/css/main.css
@@ -46,6 +46,29 @@ blockquote {
padding-left: 0.8em;
}
+/* narrow screens: reduce list indentation */
+dd,
+ol,
+ul {
+ margin: 0;
+ padding-left: 1.5em;
+}
+
+/* Narrow screens: allow hyphenating titles
+ * I can't add soft hyphens to these. */
+h1 {
+ hyphens: auto;
+}
+
+/* Very narrow screens: full hyphenation */
+@media (max-width: 180px) {
+ article,
+ h2,
+ h3 {
+ hyphens: auto
+ }
+}
+
/* single-line nav on widescreen and print.
* Single-line nav on print saves almost half a page. */
@media print, (min-width: 32em) {
diff --git a/content/posts/website-best-practices.gmi b/content/posts/website-best-practices.gmi
index ab01fcd..c81eb03 100644
--- a/content/posts/website-best-practices.gmi
+++ b/content/posts/website-best-practices.gmi
@@ -863,22 +863,28 @@ As words-per-line decrease (by increasing zoom or narrowing the viewport), line
People read on a variety of viewport sizes. Page structure must be simple enough to handle these layouts smoothly.
-### Narrow viewports
-
-A single element wider than the viewport will trigger horizontal scrolling for the entire page. This is especially problematic for long pages that already require excessive vertical scrolling.
+### Narrow viewports are popular
Not every phone has a giant screen: millions of people around the world use Web-enabled feature phones. The Jio Phone 2, for instance, is narrow enough to fall through a belt loop: it sports a screen that's just over 3.6 cm (1.44 inches) wide. Furthermore, some programs sport browser windows in sidebars:
=> https://addons.mozilla.org/en-US/firefox/addon/side-view/ Mozilla's side view
=> https://help.vivaldi.com/desktop/panels/web-panels/ Vivaldi Web Panels
-Users who leverage floating or tiling windows rather than maximizing everything could use viewports of arbitrary dimensions.
+Users who leverage floating or tiling windows rather than maximizing everything could use viewports of arbitrary dimensions. Nowadays, even smartwatches have built-in browsers; users who navigate to links in smartwatch message and email apps will use a simplified browser that fits on their wrist.
+
+=> https://developer.apple.com/videos/play/wwdc2018/239/ Apple Watch's version of WebKit (video)
+=> https://brucelawson.co.uk/2018/the-practical-value-of-semantic-html/ Text + image summary of the above video
+=> https://www.tizenhelp.com/samsung-internet-browser-now-support-on-galaxy-watch-4/ Samsung Internet on Wear OS
+
+The Apple Watch Series 6 has a viewport that's 162 CSS pixels wide. Samsung Internet is a popular option for Wear OS users, whose viewports are often just 150 CSS pixels.
### Wide items
+A single element wider than the viewport will trigger horizontal scrolling for the entire page. This is especially problematic for long pages that already require excessive vertical scrolling.
+
Long words, especially in headings, can trigger horizontal overflow. Test in a viewport that's under 240 pixels wide (DPR=1) and observe any words that trail off of the edge of the screen. Add soft hyphens to these words using the "" entity.
-Most modern browsers support the "hyphens" CSS 3 property, but full automatic hyphenation is usually an overkill solution with a naive implementation. Automatic hyphenation will insert hyphens wherever it can, not necessarily between the best syllables. At the time of writing, humans are still better at hyphenating than most software implementations. I'm also not aware of a CSS property that only breaks syllables when necessary to avoid horizontal scrolling.
+Most modern browsers support the "hyphens" CSS 3 property, but full automatic hyphenation is usually an overkill solution with a naive implementation. Automatic hyphenation will insert hyphens wherever it can, not necessarily between the best syllables. At the time of writing, humans are still better at hyphenating than most software implementations. I only enable full hyphenation on the narrowest of viewports.
Users employing machine translation will not benefit from your soft hyphens, so don't expect them to always work as intended. Translation tools might also replace short words with long ones. Soft hyphens and automatic hyphenation are both flawed solutions, but I find soft hyphens to be less problematic.
@@ -945,7 +951,7 @@ There's an ideal range somewhere between "cramped" and "spaced-apart" content. F
Excessive indentation can make reading difficult for narrow viewports, but preserving some indentation is still useful.
-For now, I've decided to keep the indents on list elements (
,
,
) since I often fill them with links. See see this article's table of contents on its Web mirror for an example:
+For now, I've decided to keep some indentation on list elements (,
,
) since I often fill them with links. See see this article's table of contents on its Web mirror for an example:
=> https://seirdy.one/2020/11/23/website-best-practices.html#toc Table of contents
diff --git a/content/posts/website-best-practices.md b/content/posts/website-best-practices.md
index fb76b3d..62a2a88 100644
--- a/content/posts/website-best-practices.md
+++ b/content/posts/website-best-practices.md
@@ -1,6 +1,6 @@
---
date: "2020-11-23T12:21:35-08:00"
-description: A lengthy guide to making simple and accessible sites that focus on content rather than form. Emphasizes brutalist web design, adaptability, and minimalism to cater to underrepresented users.
+description: A lengthy guide to making simple, inclusive sites focused on content before form. Emphasizes brutalist design and accessibility to include under-represented users.
outputs:
- html
- gemtext
@@ -36,7 +36,7 @@ I realize not everybody's going to ditch the Web and switch to Gemini or Gopher
My primary focus is [inclusive design](https://100daysofa11y.com/2019/12/03/accommodation-versus-inclusive-design/). Specifically, I focus on supporting _underrepresented ways to read a page_. Not all users load a page in a common web-browser and navigate effortlessly with their eyes and hands. Authors often neglect people who read through accessibility tools, tiny viewports, machine translators, "reading mode" implementations, the Tor network, printouts, hostile networks, and uncommon browsers, to name a few. I list more niches in [the conclusion](#conclusion). Compatibility with so many niches sounds far more daunting than it really is: if you only selectively override browser defaults and use plain-old, semantic HTML (POSH), you've done half of the work already.
-One of the core ideas behind the flavor of inclusive design I present is being _inclusive by default._ Web pages shouldn't use accessible overlays, reduced-data modes, or other personalizations if these features can be available all the time. Of course, some features conflict; you can't display a light and dark color scheme simultaneously. Personalization is a fallback strategy to resolve conflicting needs. Disproportionately underrepresented needs deserve disproportionately greater attention, so they come before personal preferences instead of being relegated to a separate lane.
+One of the core ideas behind the flavor of inclusive design I present is being _inclusive by default._ Web pages shouldn't use accessible overlays, reduced-data modes, or other personalizations if these features can be available all the time. Of course, some features conflict; you can't display a light and dark color scheme simultaneously. Personalization is a fallback strategy to resolve conflicting needs. Disproportionately underrepresented needs deserve disproportionately greater attention, so they come before personal preferences instead of being relegated to a separate lane.
Another focus is minimalism. [Progressive enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement) is a simple, safe idea that tries to incorporate some responsibility into the design process without rocking the boat too much. I don't find it radical enough. On top of progressive enhancement, I prefer limiting any enhancements to ones that have been demonstrated to solve specific accessibility, security, performance, or significant usability problems faced by people _besides me._
@@ -400,9 +400,9 @@ Searchability is another reason to prefer conveying information textually, when
### The importance of proofreading
-Correct, consistent spelling is important to readers who use search. In-page search doesn't currently pick up misspelled words. If in-page search implementations develop such a feature, some users may wish to sometimes turn it off; even Google Search implemented a "verbatim" mode for exact matches.
+Correct, consistent spelling is important to readers who use search. In-page search doesn't currently pick up misspelled words. If in-page search implementations develop such a feature, some users may wish to sometimes turn it off; even Google Search implemented a "verbatim" mode for exact matches.
-Moreover, some search implementations (such as the one built into Firefox) support case-sensitive matching. Inconsistent capitalization of proper nouns, acronyms, and initialisms can make searching difficult.
+Moreover, some search implementations (such as the one built into Firefox) support case-sensitive matching. Inconsistent capitalization of proper nouns, acronyms, and initialisms can make searching difficult.
### Problematic overrides
@@ -474,7 +474,7 @@ Accordingly, follow good practices for alt-text:
* Concisely summarize the image content the best you can, without repeating the surrounding content.
* Images with a low information density should usually have alt-text under 120 characters.
-* Don't include significant information that isn't present in the image; I'll cover how to handle supplementary information in the next subsections.
+* Don't include significant information that isn't present in the image; I'll cover how to handle supplementary information in the next subsections.
The WAI provides some guidelines in [An `alt` Decision Tree](https://www.w3.org/WAI/tutorials/images/decision-tree/). It's a little lacking in nuance, but makes for a good starting point. Remember that guidelines and "good practices" always have exceptions.
@@ -527,7 +527,7 @@ Equation
Figures and captions have loose guidelines, and nearly everything I said on the matter is full of exceptions. A figure need not have a caption, but the majority benefit from one. It need not contain a single main element, but most probably should.
-I personally try to maintain the flow of an article even if its figures and captions are completely removed or moved to an appendix. A figure is a "self-contained" block: user agents may re-position figure captions relative to the main figure content, or move the entire figure elsewhere; this is especially common in [reading-mode implementations](#non-browsers-reading-mode). The HTML specification explicitly notes this behavior.
+I personally try to maintain the flow of an article even if its figures and captions are completely removed or moved to an appendix. A figure is a "self-contained" block: user agents may re-position figure captions relative to the main figure content, or move the entire figure elsewhere; this is especially common in [reading-mode implementations](#non-browsers-reading-mode). The HTML specification explicitly notes this behavior.