Corrections to #520: diagram below the floor, and 76 more descriptions - #521
Merged
Merged
Conversation
…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.
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 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. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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) asdisplayedWidth. The actual content column at a 390px viewport is 354px.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.emulatewith390x844x3,mobile,touchgives 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:
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.
MINdrops 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 carryseo_overrideso 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-296already setsdisplay: block; overflow-x: autoon post tables under 767px and it works - a true 390px check onfractional-cto-vs-full-time-ctoshows 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-build8/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