Skip to content

docs(blog-site): add post on the per-account dark mode choice - #1100

Open
FagnerMartinsBrack wants to merge 2 commits into
mainfrom
rp/youthful-ramanujan-kfnfzx
Open

docs(blog-site): add post on the per-account dark mode choice#1100
FagnerMartinsBrack wants to merge 2 commits into
mainfrom
rp/youthful-ramanujan-kfnfzx

Conversation

@FagnerMartinsBrack

Copy link
Copy Markdown
Member

Adds one blog post announcing the per-account appearance preference that shipped in 77ff8a0: System, Light, or Dark picked once under /account, resolved server-side during SSR so a page arrives already themed, and read by the iPhone and Android apps from the same setting.

Scheduled drafting run. Topic selection notes:

  • Chosen over the Firefox AMO listing (still awaiting Mozilla review, public URL 404s), the mail-host reader gate (a privacy fix whose public disclosure should be a human call), the billing-period change (pricing is date-bound, excluded by the standing instructions), and the owner-reader caching work (performance was the topic 2 posts ago).
  • Written in Principle Voice: single claim (a theme choice belongs to the account, not each device) proven with the shipped feature. There was no live reviewer to confirm the voice with, so please treat the voice choice as part of the review.
  • Tagged changelog with banner: "I taught dark mode to follow your account", so merging moves the site-wide banner to this post.
  • Structural-variety lookback ran against the last 8 posts: opening shape, second sentence, TL;DR opener, last 2 headers, and the closing call-to-action all differ from each of them.
  • blog-site:check passes (loader parses the post, tests and coverage green). The full pre-commit pnpm check passed after seeding editorconfig-checker's pinned v3.8.0 binary locally, since this sandbox blocks its api.github.com download.

🤖 Generated with Claude Code

https://claude.ai/code/session_019FcwBxyKXmsfpxcw77896U


Generated by Claude Code

Announces 77ff8a0 to readers: System, Light, or Dark picked once under
/account, resolved server-side so a page arrives already themed, and read
by both native apps from the same setting. Tagged changelog, so the
site-wide banner moves to this post.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019FcwBxyKXmsfpxcw77896U
@FagnerMartinsBrack

Copy link
Copy Markdown
Member Author

@claude Review this PR. Use your Read tool to read the local file .github/workflows/claude-PR-code-reviewer.md for instructions. The file is in the checked-out repository.

Context

@claude

claude Bot commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Claude finished @FagnerMartinsBrack's task in 7m 5s —— View job


High Priority Issues (Must Fix)

None found

Medium Priority Issues

None found

Low Priority Suggestions

1. Voice check (you asked me to confirm this)

The Principle framing holds: the single claim — a theme choice belongs to the account, not each device — is stated in the intro and the TL;DR, and proved with the shipped feature. Register, cadence, and the ban lists are clean (no em dashes/semicolons outside the required TL;DR label, no banned words, however count 0, second person confined to the closing).

The one spot that stretches Principle's single-claim discipline is ## Dark from the first byte (lines 36–39). It introduces a second benefit — server-side resolution means no flash-of-wrong-theme — that is distinct from the cross-device claim the rest of the post argues. It's unified enough to pass (the account is the authority because the server knows whose page it is), and for a changelog announcement covering the concrete win is reasonable. My verdict: keep it. Flagging only because you explicitly asked, and this is the sentence-by-sentence call a live reviewer would have made.

2. Closing section repeats the intro's location + button count

## 3 buttons under Account (lines 49–51) restates the Account → Appearance → 3 buttons (System/Light/Dark) detail already given in the intro at line 27 (Under Account there is now a section called Appearance with 3 buttons: System, Light, and Dark). It works as the CTA, so this is optional, but the location and count land twice. Tightening the close to lead with the action rather than re-establishing where the control lives would remove the echo. Fix this →

What I verified

Accuracy against the shipped feature (77ff8a0) — every technical claim checks out:

  • 3-way choice System/Light/Dark stored on the account, resolved server-side during SSR → matches the commit and account.template.html / buildAppearanceSection.
  • "The 3 buttons are a plain form … works with JavaScript turned off" — confirmed: the appearance form is a bare <form method="POST"> with submit buttons and no hx-boost (unlike the card forms above it).
  • iPhone + Android read the same setting and theme their native chrome; the in-app reader renders on the same answer — matches iOS preferredColorScheme / Android ReadplaceTheme reading collection.appearance.
  • theme-color sent as the correct value, System stays default behind prefers-color-scheme, signed-out stays light-pinned, dark palette unchanged at 14.73:1 — all confirmed in the commit.
  • Links resolve: /blog/saved-articles-hold-up-on-e-ink exists; the MDN link correctly uses the /view/ form.

Frontmatter vs. loader schema (blog.posts.ts) — valid: slug matches filename, date regex OK, changelog tag carries the required banner:, keywords is a comma-separated string. Post will load and will drive the site-wide banner as the newest changelog post.

Structural-variety lookback (this post vs. the last 8 by date) — independently re-ran it; all shared axes differ: opening (device-personification, first word "Every" — no recent post uses it), second sentence (no snap back to "you"), TL;DR opener ("Dark …", not led by the product name), both trailing headers, and the closing CTA sentence shape. The [your readlist](/) link is reused, which the saturation map explicitly permits.

cc @FagnerMartinsBrack - No high or medium priority issues found. This PR is ready for human review.
· branch rp/youthful-ramanujan-kfnfzx

@FagnerMartinsBrack

Copy link
Copy Markdown
Member Author

High Priority Issues (Must Fix)

None found

Medium Priority Issues

None found

Low Priority Suggestions

1. Voice check (you asked me to confirm this)

The Principle framing holds: the single claim — a theme choice belongs to the account, not each device — is stated in the intro and the TL;DR, and proved with the shipped feature. Register, cadence, and the ban lists are clean (no em dashes/semicolons outside the required TL;DR label, no banned words, however count 0, second person confined to the closing).

The one spot that stretches Principle's single-claim discipline is ## Dark from the first byte (lines 36–39). It introduces a second benefit — server-side resolution means no flash-of-wrong-theme — that is distinct from the cross-device claim the rest of the post argues. It's unified enough to pass (the account is the authority because the server knows whose page it is), and for a changelog announcement covering the concrete win is reasonable. My verdict: keep it. Flagging only because you explicitly asked, and this is the sentence-by-sentence call a live reviewer would have made.

2. Closing section repeats the intro's location + button count

## 3 buttons under Account (lines 49–51) restates the Account → Appearance → 3 buttons (System/Light/Dark) detail already given in the intro at line 27 (Under Account there is now a section called Appearance with 3 buttons: System, Light, and Dark). It works as the CTA, so this is optional, but the location and count land twice. Tightening the close to lead with the action rather than re-establishing where the control lives would remove the echo.

Review on #1100 flagged the echo: the final section repeated the
Account > Appearance location and the 3-button count from the intro.
The close now leads with the action and carries the location as the
link alone.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019FcwBxyKXmsfpxcw77896U
@FagnerMartinsBrack

Copy link
Copy Markdown
Member Author

@claude Review this PR. Use your Read tool to read the local file .github/workflows/claude-PR-code-reviewer.md for instructions. The file is in the checked-out repository.

Context

@claude

claude Bot commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Claude finished @FagnerMartinsBrack's task in 4m 41s —— View job


Re-review at 95600fa1

The second commit addresses the only open item from the prior review. I re-checked the changed lines and re-ran the structural lookback on the axis that moved.

High Priority Issues (Must Fix)

None found

Medium Priority Issues

None found

Low Priority Suggestions

1. Prior suggestion #2 — resolved

The old close (## 3 buttons under Account + The switch sits in [Account](/account), under Appearance. Press Dark once…) restated the intro's Account → Appearance location and the "3 buttons" count. The rewrite leads with the action and carries the location as the link alone:

## Pick a side once

Press [Dark](/account) once, and [your readlist](/) opens dark on every screen you sign into, at noon and at midnight alike.

The echo with line 27 is gone — the intro now owns the location + count, the close owns the action. Clean fix.

2. Prior suggestion #1 — stands, no change needed

## Dark from the first byte is unchanged. My earlier verdict was "keep it" (the server-side-resolution benefit is unified with the cross-device claim: the account is the authority because the server knows whose page it is). Leaving it untouched is consistent with that. Not an action item.

3. Optional: Pick a side once reads binary against a 3-way control

The header frames the choice as two "sides", but Appearance offers 3 buttons (System, Light, Dark). It works because the paragraph under it is specifically the Dark CTA (Press [Dark](/account) once), so light-vs-dark as "two sides" is a fair light metaphor. Likely intentional, and it leads with the action as asked. Flagging only because you wanted sentence-level scrutiny — a header that fits a ternary choice (e.g. naming the once-and-done nature of the pick rather than a "side") would remove the tension with "3 buttons". Keep-or-tweak, your call. Fix this →

What this re-review checked

  • Diff scope — commit 95600fa1 touches 2 lines: the final header and the closing paragraph. Body-prose only; no frontmatter, no rp-figure, so the post's load-time validity (green at the prior commit) is unaffected.
  • Structural variety, axis e (final header) — re-ran against the last 8 posts by date. Pick a side once is the only imperative among them (the others are noun phrases and wh- clauses), shares no first word, and names the specific action rather than a generic Try it. Passes.
  • Structural variety, axis f (closing CTA) — the closing sentence already existed as the second sentence of the old close (validated last review); standing alone it still opens on Press, an imperative none of the recent closings use. The reused [your readlist](/) link is the explicitly-permitted part.
  • Axis d (second-to-last header)System keeps its job unchanged, still distinct.
  • Voice / bans on the changed lines — no banned words, no em dash, no semicolon; header casing stays sentence case, consistent with the other three. however count still 0. Second person still confined to the closing.

cc @FagnerMartinsBrack - No high or medium priority issues found. This PR is ready for human review.
· branch rp/youthful-ramanujan-kfnfzx

Copy link
Copy Markdown
Member Author

Keeping Pick a side once (re-review suggestion 3). The binary framing is deliberate: Light and Dark are the sides, and System is the choice not to pick one — the section's CTA asks the reader to override exactly that default, so the header names the decision the paragraph makes. Nothing else in the re-review is an action item, so the PR stands at 95600fa for human review.


Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants