Repository navigation
fix(cli): count line_unread words from the block's rendered text - #6456
Conversation
jrusso1020
left a comment
jrusso1020
left a comment
There was a problem hiding this comment.
Reviewed at eabf072d8f7ab4655e89bcaffeb8b97be791f755.
The glyph word-count fix is useful. I found one non-blocking accuracy follow-up at layout-audit.browser.js:2603: whole-block innerText includes opacity-hidden siblings that the readable-part filter removes. In an exact-head headless Chrome sampler control, only Hi is visible, but blockText includes 14 hidden sibling words. Five samples over two seconds through the actual detector produce a 15-word line_unread warning; the visible-only control produces none.
Nit: build block text from nodes passing the same readability opacity, visibility and clipping filters, preserving DOM whitespace. Add opacity 0/below 0.5 sibling cases alongside the existing glyph tests. I checked the downstream consumer: checkPipeline.ts:1915 explicitly excludes craft warnings from the strict gate, and check.test.ts:2193 pins exit 0 even under --strict. This false warning does not fail the check, so I am leaving the bounded follow-up non-blocking.
The authored craftAudit suite passes 21 tests. The extra witness exercises the actual browser sampler and analyzer with synthetic frames, not a full animated-film render. No full workspace run.
Need: yes · Size: ok · Reuse: existing readable-part sampler · Simpler: keep one visibility-aware text source · Structure: fine
Risk: low - advisory text audit accuracy; render and check success remain unchanged.
Verdict: APPROVE
Reasoning: The main word-count correction holds; the measured hidden-word warning is a focused follow-up.
Reasoning: The glyph word-count fix is useful; the remaining hidden-word case is advisory and explicitly does not gate check, even under --strict.
What
line_unreadnow counts a block's words from the block's rendered text (innerText) instead of joining its parts with spaces.Why
A line built from one
<span>per glyph arrives as one part per character, soreadableBlocksjoined it intoT h a t c a m e r a …and counted every letter as a word (25 instead of 7). The parts don't carry the author's whitespace, so the join can't know where words break.Related work
Fixes #6443 (the fix suggested in the issue).
How
craftTextPartsalso reportsblockText: textContentFor(block, false)for each part.readableBlockstakes the block's text from it and still unions the parts' rects.Test plan
Ran the issue's repro through
hyperframes check:line_unreadno longer fires on#spans, and only the expecteddead_stretchremains. I used Claude Code to write this change; I reviewed it myself.