1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-10 00:12:09 +00:00

Compare commits

...

4 commits

Author SHA1 Message Date
Rohan Kumar
42722afe60
New note: ai generated alt + img 2022-08-05 23:51:19 -07:00
Rohan Kumar
7cf0e4bc9b
Internal: check-whole-site: deploy in parallel
Saves about a minute of time.
2022-08-05 22:49:18 -07:00
Rohan Kumar
2ed2bf3c88
More info on optimizing perf for very long pages
Add information about performance of the accessibility tree and how to
offset some difficulties caused by large DOM trees.
2022-08-05 22:41:31 -07:00
Rohan Kumar
d02b749425
More stylesheet tweaks
- Increase list padding so that ordered-list decimal markers have space
  to fit without overflowing.
- Improve style for removing underline between h-card name and photo, so
  it doesn't apply to any unnecessary elements.
- Reduce budget for document size.
2022-08-05 07:24:16 -07:00
10 changed files with 90 additions and 29 deletions

View file

@ -14,6 +14,7 @@ GEMINI_RSYNC_DEST = $(USER):$(GEMINI_ROOT)
OUTPUT_DIR = public
RSYNCFLAGS += -rlpcv --zc=zstd --zl=6 --skip-compress=gz/br/zst/png/webp/jpg/avif/jxl/mp4/mkv/webm/opus/mp3
RSYNCFLAGS_EXTRA ?=
# compression gets slow for extreme levels like the old "70109"
ECT_LEVEL=9
@ -66,14 +67,14 @@ htmlproofer:
htmlproofer $(OUTPUT_DIR) --disable-external --report-invalid-tags --report-missing-names --report-missing-doctype --report-eof-tags --report-mismatched-tags --check-html --check-opengraph --check-favicon --empty-alt-ignore --file-ignore $(OUTPUT_DIR)/search/index.html --url-ignore '../music.txt'
linter-configs/htmltest.yml:
rsync $(RSYNCFLAGS) deploy@seirdy.one:/home/deploy/refcache.json linter-configs/htmltest/refcache.json
rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) deploy@seirdy.one:/home/deploy/refcache.json linter-configs/htmltest/refcache.json
# basic checks for generated HTML and broken links. Persist the broken
# link cache remotely so we can run this in CI.
.PHONY: htmltest
htmltest: linter-configs/htmltest.yml
htmltest -c linter-configs/htmltest.yml $(OUTPUT_DIR)
rsync $(RSYNCFLAGS) linter-configs/htmltest/refcache.json deploy@seirdy.one:/home/deploy/refcache.json
rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) linter-configs/htmltest/refcache.json deploy@seirdy.one:/home/deploy/refcache.json
.PHONY: hint
hint: hugo .hintrc-local
@ -122,11 +123,11 @@ mentions.json: hugo
.PHONY: deploy-html
deploy-html:
rsync $(RSYNCFLAGS) --exclude 'gemini' --exclude '*.gmi' --exclude-from .rsyncignore $(OUTPUT_DIR)/ $(WWW_RSYNC_DEST) --delete
rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) --exclude 'gemini' --exclude '*.gmi' --exclude-from .rsyncignore $(OUTPUT_DIR)/ $(WWW_RSYNC_DEST) --delete
.PHONY: deploy-gemini
deploy-gemini:
rsync $(RSYNCFLAGS) --exclude '*.html' --exclude '*.xml' --exclude '*.xhtml' --exclude '*.gz' --exclude '*.br' --exclude-from .rsyncignore $(OUTPUT_DIR)/gemini/ $(OUTPUT_DIR)/about $(OUTPUT_DIR)/posts $(OUTPUT_DIR)/about $(OUTPUT_DIR)/publickey.* $(GEMINI_RSYNC_DEST)/ --delete
rsync $(RSYNCFLAGS) $(RSYNCFLAGS_EXTRA) --exclude '*.html' --exclude '*.xml' --exclude '*.xhtml' --exclude '*.gz' --exclude '*.br' --exclude-from .rsyncignore $(OUTPUT_DIR)/gemini/ $(OUTPUT_DIR)/about $(OUTPUT_DIR)/posts $(OUTPUT_DIR)/about $(OUTPUT_DIR)/publickey.* $(GEMINI_RSYNC_DEST)/ --delete
.PHONY: deploy
deploy: deploy-html deploy-gemini

View file

@ -367,12 +367,13 @@ sup {
/* narrow screens: reduce list indentation, hyphenate nested lists
* touch screens: lists of links should be easy to tap so give them
* some spacing (partial SC 2.5.5). There should be non-interactive
* space to the left that's safe to tap. */
* space to the left that's safe to tap.
* 1.75em is the minimum required for ol numbers to fit. */
dd,
ol,
ul {
margin: 0;
padding-left: 1.5em;
padding-left: 1.75em;
}
blockquote,
@ -425,8 +426,12 @@ h1 {
hyphens: auto;
}
/* Very narrow screens: full hyphenation.
* This is the typical width of a smart feature phone. */
/* Very narrow screens: full hyphenation, compactness
* This is the typical width of a smart feature phone, or a browser
* sidebar. At this tiny width, users are either unlikely to be using a
* touchscreen (KaiOS-like feature phones, desktop browser sidebars) or
* they're just reading non-interactively. being compact probably takes
* precedence over being touch-friendly. */
@media (max-width: 272px) {
body {
font-size: 100%;
@ -441,6 +446,10 @@ h1 {
padding: .25em;
}
dd {
padding-left: 1em;
}
hr {
margin: .25em 0;
}
@ -565,11 +574,11 @@ summary {
vertical-align: -.1em;
}
.h-card a.u-uid {
.p-author a.u-uid {
text-decoration: none;
}
a .p-name {
a .u-photo + .p-name {
text-decoration: underline;
}

View file

@ -0,0 +1,15 @@
---
title: "Re: AI-Generated Images from AI-Generated Alt Text"
date: 2022-08-05T23:50:16-07:00
replyURI: "https://adrianroselli.com/2022/08/ai-generated-images-from-ai-generated-alt-text.html"
replyTitle: "AI-Generated Images from AI-Generated Alt Text"
replyType: "BlogPosting"
replyAuthor: "Adrian Roselli"
replyAuthorURI: "https://adrianroselli.com/"
---
This is a great post to illustrate the utility of detailed alt-text when an image is the primary content. I think it's less relevant for the more common use of images: as illustrative examples or supplements to surrounding text.
Take an image embedded in an article. Sighted users are capable of viewing a detailed image and instantly filtering for the information that's relevant to the surrounding content. It's harder to do this with a blurb of text, so this situation would call for more a more brief description.
The opposite extreme: the most detailed textual alternatives I work with are image transcripts (e.g. for comics). Flat text is a poor fit; semantic HTML works better. I'm hoping aria-details gains traction in the future and settling for [short alt + long `aria-describedby` text](https://seirdy.one/posts/2020/11/23/website-best-practices/#image-transcripts) in the meantime.

View file

@ -356,14 +356,15 @@ A hybrid between the two is paginated content in which users click a "load next
I've discussed loading pages in the background, but what about saving a page offline (e.g. with Ctrl + s)? While lazy-loading won't interfere with the ability to save a complete page offline, some of these related issues can. Excessive pagination and inline scrolling make it impossible to download a complete page without manually scrolling or following pagination links to the end.
### Other ways to defer content
## Long-page performance
Deferring network requests is a bad idea, but there are other ways to improve large-page performance.
A similar image attribute that I *do* recommend is the "decoding" attribute. I typically use `decoding="async"` so that image decoding can be deferred.
Deferring network requests is a bad idea, as established in the previous “Against lazy loading” section. There are other ways to improve large-page performance.
An alternative to the loading attribute that I do recommend is the decoding attribute. I typically use decoding="async" so that image decoding can be deferred.
=> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding <img> decoding on MDN
### CSS containment
Long pages with many DOM nodes may benefit from CSS containment, a more recently-adopted part of the CSS specification.
CSS containment allows authors to isolate sub-trees of the DOM. This lets browsers make more informed optimizations: they can delay painting off-screen content or reduce re-calculations when isolated nodes change. Combined with a property like "content-visibility", it enables browsers to defer all rendering of less essential below-the-fold content.
@ -378,13 +379,29 @@ Using containment for content at the end of the page is relatively safe. Using i
The benefits of containment are especially noticeable when injecting styles into a page. "Dark mode" extensions perform noticeably better when enough elements receive layout and paint containment.
# Performance of assistive technologies
Eric Baileys gave a presentation describes how computing the accessibility tree can be expensive if a page has too many DOM nodes and custom elements:
=> https://noti.st/ericwbailey/Yfyaxa/slides The intersection of performance and accessibility
Browsers use complex heuristics to determine which elements to report, to reduce the size of the accessibility tree. Now that all major browsers are moving to multi-process architectures, some browser components interface with assistive technology (AT) in a separate process. Data about the pages semantics needs to cross process boundaries, incurring additional overhead.
Re-calculating nodes in the accessibility tree can create small delays for user interaction. These delays add up, causing the accessibility tree to fall out-of-sync with the actual page state. In extreme cases, an out-of-control accessibility tree may crash the AT. Moreover, speech synthesizers may be slow to start speaking when the CPU is under load. Delayed speech synthesis is incredibly annoying because it tends to omit words while “warming up”.
When pages grow long, keep performance in check by doing the following:
* Prefer semantic HTML over custom elements. The browsers accessibility-tree-generation and element-filtering is optimized for semantic HTML; it has to do more guesswork to decipher custom elements.
* Avoid scripts that delay user-input or cause complex DOM mutations. These will introduce delays that can cause significant AT usability issues.
* Remember that CSS can impact the accessibility tree. Avoid using scripts to alter properties such as "display" and "visibility".
* Test with screen readers on underpowered hardware. Examples include old entry-level Android phones and netbooks with aggressive thermal throttling.
## In-page search
In-page search (e.g., using "Ctrl + f") has been a basic feature in document readers well before browsers, and continues to be an essential feature today.
Searchability is a good reason to prefer conveying information textually, when possible: video (especially without accurate captions), pictures of text, etc. aren't so easily searchable.
Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; Reddit's atrocious redesign is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in the "other ways to defer content" section.
Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; Reddit's atrocious redesign is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in the "Long-page performance" section.
=> gemini://seirdy.one/misc/find.png searching for the word "good" in the phrase "I wonder how much good a" when a "see more" link obscures the match, before and after revealing the hidden text. From the Reddit redesign.

View file

@ -397,11 +397,14 @@ Caption below the panel
{{< /transcribed-image-transcript >}} {{< /transcribed-image >}}
### Other ways to defer content
Long-page performance
---------------------
Deferring network requests is a bad idea, but there are other ways to improve large-page performance.
Deferring network requests is a bad idea, as established in the [previous "Against lazy loading" section](#against-lazy-loading). There are other ways to improve large-page performance.
A similar image attribute that I _do_ recommend is the [`decoding` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding). I typically use `decoding="async"` so that image decoding can be deferred.
An alternative to the `loading` attribute that I _do_ recommend is the [`decoding` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding). I typically use `decoding="async"` so that image decoding can be deferred.
### CSS containment
Long pages with many DOM nodes may benefit from CSS containment, a more recently-adopted part of the CSS specification.[^10]
@ -424,6 +427,22 @@ Leveraging containment and `content-visibility` is a progressive enhancement, so
Using containment for content at the end of the page is relatively safe. Using it for content earlier in the page risks introducing [layout shifts](#layout-shifts). Eliminate the layout shifts by calculating a value for the `contain-intrinsic-size` property. {{<mention-work itemtype="TechArticle">}}{{<cited-work url="https://www.terluinwebdesign.nl/en/css/calculating-contain-intrinsic-size-for-content-visibility/" name="Calculating 'contain-intrinsic-size' for 'content-visibility'" extraName="headline">}}, by {{<indieweb-person first-name="Thijs" last-name="Terluin" url="https://www.terluinwebdesign.nl/en/about-us/thijs-terluin/" org="Teluin Webdesign" org-url="https://www.terluinwebdesign.nl/en/" itemprop="author">}}{{</mention-work>}}, is a comprehensive guide to calculating intrinsic size values.
### Performance of assistive technologies
{{<mention-work itemtype="CreativeWork" itemprop="mentions">}}{{<indieweb-person first-name="Eric" last-name="Bailey" url="https://ericwbailey.design/" itemprop="author" appendString="s">}} presentation {{<cited-work name="The intersection of performance and accessibility" url="https://noti.st/ericwbailey/Yfyaxa/slides">}}{{</mention-work>}} describes how computing the accessibility tree can be expensive if a page has too many DOM nodes and custom elements. Browsers use complex heuristics to determine which elements to report, to reduce the size of the accessibility tree. Now that all major browsers are moving to multi-process architectures, some browser components interface with assistive technology (<abbr>AT</abbr>) in a separate process. Data about the page's semantics needs to cross process boundaries, incurring additional overhead.
Re-calculating nodes in the accessibility tree can create small delays for user interaction. These delays add up, causing the accessibility tree to fall out-of-sync with the actual page state. In extreme cases, an out-of-control accessibility tree may crash the <abbr>AT</abbr>. Moreover, speech synthesizers may be slow to start speaking when the CPU is under load. Delayed speech synthesis is incredibly annoying because it tends to omit words while "warming up".
When pages grow long, keep performance in check by doing the following:
* Prefer semantic HTML over custom elements. The browser's accessibility-tree-generation and element-filtering is optimized for semantic HTML; it has to do more guesswork to decipher custom elements.
* Avoid scripts that delay user-input or cause complex DOM mutations. These will introduce delays that can cause significant <abbr>AT</abbr> usability issues.
* Remember that CSS can impact the accessibility tree. Avoid using scripts to alter properties such as `display` and `visibility`.
* Test with screen readers on underpowered hardware. Examples include old entry-level Android phones and netbooks with aggressive thermal throttling.
In-page search
--------------
@ -431,7 +450,7 @@ In-page search (e.g., using <kbd>Ctrl</kbd> + <kbd>f</kbd>) has been a basic fea
Searchability is a good reason to prefer conveying information textually, when possible: video (especially without accurate captions), pictures of text, etc. aren't so easily searchable.
Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; [Reddit's atrocious redesign](#reddit-redesign) is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in [the "other ways to defer content" section](#other-ways-to-defer-content).
Web pages that hide content behind "show content" widgets are difficult to search through: users need to toggle "show content" for each item they wish to search. Often, in-page search highlights are hidden; [Reddit's atrocious redesign](#reddit-redesign) is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in [the "Long-page performance" section](#long-page-performance).
{{<image-figure id="reddit-redesign">}}

View file

@ -22,7 +22,6 @@
(btw this is all made of <span> cuz it is supposed to be inline)
--><span itemprop="author copyrightHolder" itemscope="" itemtype="https://schema.org/Person" itemid="https://seirdy.one/#seirdy" class="h-card p-author author vcard">
<a itemprop="url" href="https://seirdy.one/" rel="author me home cc:attributionURL" class="u-url u-uid url" property="cc:attributionName">
{{ partial "indieweb-icon.html" }}
<span itemprop="name" class="p-name fn n">
{{ partial "indieweb-icon.html" -}} <span itemprop="name" class="p-name fn n">
<span itemprop="givenName" class="p-given-name given-name">Rohan</span>&#160;<span itemprop="familyName" class="p-family-name family-name">Kumar</span></span></a>
</span>

View file

@ -2,9 +2,9 @@
{{- $favicon_base64 := $favicon.Content | base64Encode -}}
{{- $favicon_svg := resources.Get "/favicon.svg" | resources.Fingerprint "md5" -}}
{{- if in site.BaseURL ".onion" -}}
<img itemprop="image" class="u-photo photo" width="16" height="16" alt=""
src="data:image/png;base64,{{ $favicon_base64 }}" />
<img itemprop="image" width="16" height="16" alt=""
src="data:image/png;base64,{{ $favicon_base64 }}" class="u-photo photo" />
{{- else -}}
<img itemprop="image" class="u-photo photo" width="16" height="16" alt=""
src="{{ $favicon_svg.Permalink }}" />
<img itemprop="image" width="16" height="16" alt=""
src="{{ $favicon_svg.Permalink }}" class="u-photo photo" />
{{- end }}

View file

@ -31,7 +31,7 @@
},
{
"resourceType": "document",
"budget": 75
"budget": 70
},
{
"resourceType": "image",

View file

@ -61,8 +61,9 @@ base_url="${1-http://localhost:8089}"
# HTML validation is already parallelized, so run that single-threaded.
make -j1 HUGO_FLAGS=-DF HUGO_BASEURL="$base_url" clean hugo xhtmlize validate-html
make -j "$jobs" -f Makefile.online HUGO_BASEURL="$base_url" all-extra URLS="$(curl -sSL "$base_url/sitemap.xml" | htmlq loc -t | rg -v '/search/$' | tr '\n' ' ')"
make deploy-staging -j "$jobs"
make -j "$jobs" -f Makefile.online HUGO_BASEURL="$base_url" all-extra URLS="$(curl -sSL "$base_url/sitemap.xml" | htmlq loc -t | rg -v '/search/$' | tr '\n' ' ')" &
make deploy-staging RSYNCFLAGS_EXTRA=-q
wait
make -f Makefile.online hint-online URLS="$(curl -sSL --compressed https://staging.seirdy.one/sitemap.xml | htmlq loc -t | rg -v '/(?:search|wcag-is-a-starting-point)/$' | sort | tr '\n' ' ')"
# TODO: run lighthouse on every page in the sitemap.

View file

@ -35,7 +35,7 @@ sed 7d "$html_file" | xmllint --format --encode UTF-8 --noent - | sd '^\t(?:\t)?
| sd '<pre(?: tabindex="0")?>\n\t*<(code|samp)( |>)' '<pre tabindex="0"><$1$2' \
| sd '(?:\n)?</(code|samp)>\n(?:[\t\s]*)?</pre>' '</$1></pre>' \
| sd '</span>.span itemprop="familyName"' '</span> <span itemprop="familyName"' \
| sd '(</picture>|src="[^"]*" ?/>)<span itemprop="name" class="p-name fn n">' '$1 <span itemprop="name" class="p-name fn n">' \
| sd -f m 'class="u-photo photo"[^<]*<' 'class="u-photo photo"/> <' \
| sd '([a-z])<(data|time)' '$1 <$2' \
| sd '</span>(<a[^>]*rel="(?:nofollow ugc|ugc nofollow)"(?:[^>]*)?>liked</a>)' '</span> $1' \
| sd -s '/>' ' />'