Severity: low. Nothing is broken. But the tool's value is entirely in whether someone reads its output, and pointed at a screen it produces a list nobody will read twice.
What happened
Ran it against the app's own home screen, served locally:
node tools/look.js http://127.0.0.1:8477/index.html --out ...
Result: 41 faint, 1 blank. Every one of them is correct by the tool's own rules and irrelevant to the page it was given.
28 faint text luminance 1.00 is too light to photocopy
button.btn "Make my answer sheet"
29 faint Top rule at luminance 0.66 will not survive a copy
button.btn "Set it up myself"
...
42 blank 38% of page 1 is one empty block, about 11.5in by 5.9in
White text on a coloured button is a defect on paper and correct on screen. A 0.66-luminance button border is a defect on paper and correct on screen. "11.5in by 5.9in" of a web page is a unit that does not apply.
Cause
There is no way to tell the tool what kind of page it was handed. The flags are --out, --json, --quiet — that is the whole surface. The only exclusion mechanism is per-element:
/* Anything marked noprint is screen furniture - a toolbar, a print button - */
const all = [...document.querySelectorAll('body *')].filter(el => !el.closest('.noprint'));So the tool assumes every page is destined for paper, and every element not individually marked .noprint is printable ink. Thresholds confirm it — PRINT_GREY = 0.62, BLANK_FRAC = 0.24 "measured across the four documents this project prints".
That is a coherent design for what the tool was built for. The mismatch is with what it says it is:
look.js - eyes for printed and rendered pages.
faint, tiny and blank are photocopier checks and mean nothing on a screen. truncated, collision and escaped are the three that matter in both places — and those are the ones the tool's own header describes as the defects that motivated it ("an option whose text was cut off mid-word so the correct answer could not be read"). Right now they arrive buried under 41 lines of print-only noise.
Why bother
The header states the tool's own thesis:
Every layout defect found in this project so far was found by a person noticing it, not by a test.
A findings list that is 41/42 irrelevant on a page it accepts without complaint trains its reader to skim, and the one real truncated finding on the day it appears gets skimmed with the rest. The tool is the answer to "nobody notices"; a cry-wolf list recreates the problem one layer up.
Suggested fixes
Cheapest first, any one of these is enough:
- A
--screen flag that suppresses faint, tiny and blank, and keeps truncated, collision and escaped. Roughly a one-line filter on the findings array plus a usage line.
- Refuse rather than guess. If no mode is given and the target is an
http(s) URL with no @media print stylesheet, print not checked: no page mode given — pass --print or --screen and exit non-zero. Better to say "I could not determine what this is" than to answer confidently for the wrong medium.
- Or narrow the docstring to "printed pages" and have it decline non-print targets. That is the smallest change and it is honest — the tool is good at what it does and does not need to claim the other half.
Option 1 is probably worth it on its own merits: truncated and collision on the live app at phone width (QG_W=430) is a check this project would benefit from, and it is unreachable today without wading through the print findings.
Found while red-teaming the app; the tool was pointed at a target it accepts and has no mode for, so this is about the missing mode rather than misuse.
Severity: low. Nothing is broken. But the tool's value is entirely in whether someone reads its output, and pointed at a screen it produces a list nobody will read twice.
What happened
Ran it against the app's own home screen, served locally:
Result: 41 faint, 1 blank. Every one of them is correct by the tool's own rules and irrelevant to the page it was given.
White text on a coloured button is a defect on paper and correct on screen. A 0.66-luminance button border is a defect on paper and correct on screen. "11.5in by 5.9in" of a web page is a unit that does not apply.
Cause
There is no way to tell the tool what kind of page it was handed. The flags are
--out,--json,--quiet— that is the whole surface. The only exclusion mechanism is per-element:So the tool assumes every page is destined for paper, and every element not individually marked
.noprintis printable ink. Thresholds confirm it —PRINT_GREY = 0.62,BLANK_FRAC = 0.24"measured across the four documents this project prints".That is a coherent design for what the tool was built for. The mismatch is with what it says it is:
faint,tinyandblankare photocopier checks and mean nothing on a screen.truncated,collisionandescapedare the three that matter in both places — and those are the ones the tool's own header describes as the defects that motivated it ("an option whose text was cut off mid-word so the correct answer could not be read"). Right now they arrive buried under 41 lines of print-only noise.Why bother
The header states the tool's own thesis:
A findings list that is 41/42 irrelevant on a page it accepts without complaint trains its reader to skim, and the one real
truncatedfinding on the day it appears gets skimmed with the rest. The tool is the answer to "nobody notices"; a cry-wolf list recreates the problem one layer up.Suggested fixes
Cheapest first, any one of these is enough:
--screenflag that suppressesfaint,tinyandblank, and keepstruncated,collisionandescaped. Roughly a one-line filter on the findings array plus a usage line.http(s)URL with no@media printstylesheet, printnot checked: no page mode given — pass --print or --screenand exit non-zero. Better to say "I could not determine what this is" than to answer confidently for the wrong medium.Option 1 is probably worth it on its own merits:
truncatedandcollisionon the live app at phone width (QG_W=430) is a check this project would benefit from, and it is unreachable today without wading through the print findings.Found while red-teaming the app; the tool was pointed at a target it accepts and has no mode for, so this is about the missing mode rather than misuse.