Skip to content

Corrections to #520: diagram below the floor, and 76 more descriptions - #521

Merged
pftg merged 2 commits into
masterfrom
content/floor-fix-and-remaining-descriptions
Aug 20, 2026
Merged

pftg merged 2 commits into
masterfrom
content/floor-fix-and-remaining-descriptions

Conversation

@pftg

@pftg pftg commented Aug 20, 2026

Copy link
Copy Markdown
Member

Follow-up to #520. Two commits, both corrections to work in that PR.

1. R2's diagram was below the 9px floor, and I reported it as passing

The floor formula is minFontSize * (displayedWidth / viewBoxWidth). I used the viewport width (390) as displayedWidth. The actual content column at a 390px viewport is 354px.

  • reported: 9.36px, passes
  • actual: 8.5px, fails

Two measurement faults behind that. chrome-devtools resize_page(390) does not give a 390px CSS viewport - it clamps at 500, so every "390px mobile" check in #520 was taken at 500. emulate with 390x844x3,mobile,touch gives a true 390.

Narrowing the labels made it worse - the viewBox went 478 then 488 - because mermaid width is driven by parallel columns, not label length, exactly as the pipeline warns. A branching decision tree cannot clear this floor. Rebuilt as a vertical ladder: 272px viewBox, 12px rendered, verified in-browser at a true 390.

R3 (257px) and the Kamal post (272px) re-checked against the 354px column; both pass.

2. "plain HTTP" is not a term

Paul flagged it: developers say raw HTTP. I introduced "plain HTTP" during #520's plain-English pass, which was backwards - plain English means cutting abstractions the reader must decode, not replacing established terminology with words I invented. Reverted.

3. The remaining 92 descriptions - 76 recovered

#520 left 92 for a human. Diagnosing them showed they were not one problem:

Count Why the first pass skipped it
63 First sentence complete, but under my 90-char minimum (83, 69 chars)
26 First sentence longer than 158 (159, 209 chars)
4 First prose line has no sentence ending

The 63 were an artificial floor I invented - I had conflated "short" with "fragment". A complete 83-character sentence is a good description; a 158-character dangling clause is not. MIN drops to 55.

For the 26, the fix walks further into the body for a sentence that fits rather than cutting the long one at a clause boundary. Clause cutting is what produced the dangling text in #520's first attempt.

76 rebuilt, 17 remain. Site-wide, truncated descriptions go 234 -> 17. Verified across all 76: zero end in ..., zero end without terminal punctuation, and all 76 dev.to-backed files carry seo_override so the 10-minute sync cron cannot revert them.

The 17 are announcement posts and link roundups whose opening prose offers no usable sentence. They need writing; a script should not guess.

Retraction from #520

There is no theme-level table overflow bug. I reported one. single-post.css:287-296 already sets display: block; overflow-x: auto on post tables under 767px and it works - a true 390px check on fractional-cto-vs-full-time-cto shows both tables scrolling inside themselves (406 and 420 in a 354 container) with no page overflow.

My original diagnosis read getComputedStyle(t.parentElement) - the wrapper DIV - when the rule targets the table itself. Dropping R2's Raw HTTP column in #520 was therefore not required. It stays dropped on content grounds, since every cell read "you write it".

Gates

bin/hugo-build 8/8. Local macOS suite per Paul's instruction rather than CI.

Branch cut fresh from master and cherry-picked: #520 was squash-merged, so a plain rebase would replay already-merged commits and conflict with their own content. 79 files here, not the 229 a rebase showed.

🤖 Generated with Claude Code

pftg added 2 commits August 21, 2026 01:42
…is not a term

Two corrections, both mine.

1. THE FLOOR MEASUREMENT WAS WRONG ALL SESSION. The formula is
   minFontSize * (displayedWidth / viewBoxWidth). I used the VIEWPORT
   width (390) as displayedWidth. The actual content column at a 390px
   viewport is 354px. R2's diagram measured 9.36px by my arithmetic and
   8.5px in reality - below the floor, and shipped.

   Worse, chrome-devtools resize_page(390) does not give a 390px CSS
   viewport; it clamps at 500. Every "390px mobile" check I reported
   this session was actually taken at 500. `emulate` with
   390x844x3,mobile,touch gives a true 390.

   Narrowing labels did not fix it - the viewBox went UP, 478 then 488 -
   because mermaid width is driven by parallel columns, not label
   length, exactly as the pipeline warns. A branching decision tree
   cannot clear this floor. Rebuilt as a vertical ladder: 272px viewBox,
   12px rendered, verified in the browser at a true 390 viewport.

   R3 (257px) and the Kamal post (272px) were re-checked against the
   354px column and both pass.

2. "plain HTTP" is not a term. Paul flagged it: "raw HTTP" is what
   developers call this. I introduced it during the plain-English pass,
   which was the wrong move - plain English means cutting abstractions
   the reader must decode, not swapping established terminology for
   words I invented. Reverted everywhere in this post.

RETRACTION, recorded because I reported it to Paul as fact: there is NO
theme-level table overflow bug. single-post.css:287-296 already sets
display:block + overflow-x:auto on post tables under 767px, and it
works - a true 390px check on fractional-cto-vs-full-time-cto shows both
tables scrolling inside themselves (406 and 420 in a 354 container) with
no page overflow. My original diagnosis read
getComputedStyle(parentElement) - the wrapper DIV - when the rule
targets the table itself. Dropping R2's Raw HTTP column was therefore
not required; it stays dropped on content grounds, since every cell read
"you write it".

bin/hugo-build 8/8.
… human

Diagnosed before fixing, because the 92 were not one problem:

  63  first sentence complete, but under my 90-char minimum (83, 69 chars)
  26  first sentence longer than 158 (159, 209 chars)
   4  first prose line has no sentence ending at all

The 63 were an artificial floor I had invented. A complete 83-character
sentence is a perfectly good meta description - what has to be avoided is
a FRAGMENT, not a short sentence, and I had conflated the two. MIN drops
to 55.

For the 26, the fix is to walk further into the body for a sentence that
fits rather than cutting the long one at a clause boundary. Clause cutting
is exactly what produced the dangling text in the first attempt.

Result: 76 rebuilt, 17 still skipped, lengths 59-156. Verified across all
76 written: zero end in "...", zero end without terminal punctuation, and
all 76 dev.to-backed files carry seo_override so the 10-minute sync cron
cannot revert them.

Site-wide, truncated descriptions go 234 -> 17. The remaining 17 are posts
whose opening prose genuinely offers no usable sentence - announcement
posts and link roundups, mostly. Those need writing, and a script should
not guess at them.

bin/hugo-build 8/8.
@coderabbitai

coderabbitai Bot commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: a6a00b71-6946-4423-8136-4564f2b76872


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@pftg
pftg merged commit e680684 into master Aug 20, 2026
4 checks passed
@pftg
pftg deleted the content/floor-fix-and-remaining-descriptions branch August 20, 2026 23:47
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.

1 participant