pbakaus_impeccable

1,818 Commits 103 Branches 69 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Paul Bakaus GitHub Claude	ac0416b655	Stop assuming white when a background cannot be read (#541 ) * Stop assuming white when a background cannot be read Dark themes came back from a scan buried in low-contrast findings that all claimed the light text sat on #ffffff. Two live runs against impeccable.style produced 102 and 95 of them. Two causes, both fixed here. Parsing. Browsers keep the authored color space in getComputedStyle output: oklch() stayed oklch, but color-mix results come back as color(srgb 1.04 0.72 -0.21), wide-gamut authors get color(display-p3 ...), and lch()/lab() survive verbatim. The parser read none of those, so those surfaces registered as unset. parseGradientColors was worse: it matched only rgba() and #hex, so a ground painted as linear-gradient(oklch(...), oklch(...)) counted as a gradient with no stops at all. Guessing. When the ancestor walk ran out of readable color it returned white, and on a body-level gradient it returned white without even looking. Light copy on a lacquer-black page then measured 1.3:1 against a canvas the visitor never sees. resolveBackgroundInfo now separates three outcomes: a resolved surface, a gradient the caller should fall back to stops for, and an unreadable layer. The last one makes both color adapters skip their contrast checks entirely. White survives in exactly one case, the one that earns it: every layer up to the document root was genuinely transparent. Color conversions moved to cli/engine/shared/color.mjs and gained lab, lch, and color() for srgb, srgb-linear, and display-p3. Spaces outside that set return null, which now routes to abstention rather than to a color nobody painted. Every conversion is pinned against what Chrome itself paints for the same string. Rescanning impeccable.style: 102 low-contrast findings down to 30, none of them on an invented white ground. Assisted-by: Claude Code * fix: address PR review bot findings on background resolution - Treat a url() image layer stacked above a gradient as an occluding, unreadable surface: resolveBackgroundInfo now returns unresolved so the gradient-stop fallback never measures stops the image hides (greptile-apps finding, reproduced in Chrome). - Route the glow and AI-palette DOM adapters through resolveBackgroundInfo so an unresolved surface makes them abstain instead of hunting gradient ancestors past an unreadable layer (Cursor Bugbot finding). - Resolve background-color keywords jsdom hands through verbatim: inherit now reads as no-paint (the ancestor walk IS its resolution) and currentcolor substitutes the element's own computed text color instead of forcing an abstention (Copilot finding). - Regression coverage in the dark-theme fixture for all three, asserted in both the jsdom and real-Chrome suites; browser detector regenerated. AI-assisted: prepared with Claude Code at the maintainer's direction. Co-Authored-By: Claude <noreply@anthropic.com> * fix: keep zero-offset glow findings when the surface is unreadable The browser glow adapter abstained from the whole element when resolveBackgroundInfo reported an unreadable surface, which also dropped zero-offset chromatic halo findings that do not depend on the background at all. It now skips only the gradient hunt past the unreadable layer and scores the halo tell against a null surface, matching what the static loop already did. Fixture cases pin both sides: the halo over a url() image ancestor flags in both engines, and an offset chromatic shadow on the same unknown surface stays abstained. Also hardens the currentcolor background substitution with the parseColorResolved fallback used by the text-color path, and adds fixture coverage proving tokenized currentcolor surfaces already resolve through the static cascade (flag when knowable, abstain when the token is undefined). Addresses Cursor Bugbot review findings on PR #541. AI-assisted-by: Claude Code Co-Authored-By: Claude <noreply@anthropic.com> * fix: abstain on translucent gradients over images, drop phantom color-mix stops Two follow-up review findings on the merge with main. A gradient leading a url() layer was treated as a resolvable surface even when its stops are translucent, so the glow and AI-palette hunts averaged wash stops (a 20% black wash reads as pure black) while the real surface blends with image pixels the engine cannot read. resolveBackgroundInfo now marks gradient-over-image unresolved unless every readable stop of the leading gradient is opaque, in which case the gradient provably covers the image and remains the scorable surface. parseGradientColorsModern predated this branch's parseGradientColors rewrite: its second regex pass re-extracted color tokens nested inside color-mix() stops that the shared parser already captures whole via balanced-paren tokens, appending ingredient colors that are never painted. The worst-case stop ratio then invented low-contrast findings against a color nobody sees. The helper is removed; all callers use the shared parser, which covers the modern syntaxes it existed for. Fixture coverage pins both: the translucent-wash-over-image glow abstains in both engines, an opaque gradient over an image still flags in the browser, and the color-mix wash case stays clean in the static engine. Each new assertion was verified to fail against the previous engine. Addresses Greptile and Cursor Bugbot review findings on PR #541. AI-assisted-by: Claude Code Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-08-11 14:59:07 -04:00
Paul BakausandClaude Fable 5	0d72991bc8	detector: catch glow shadows in any color format, zero-offset halos on any background, and text-shadow glows - parseAnyColor now covers oklab(), hsl()/hsla(), hwb(), and ~35 common named colors on top of rgb/rgba/hex/oklch, so checkGlow sees the color regardless of authoring format (Chrome preserves oklch() in computed styles, which the old rgba-only match silently passed). - checkGlow gains a second tell: a zero-offset chromatic box/text-shadow with blur > 4px is flagged on ANY background (the halo pattern); achromatic zero-offset shadows and focus rings stay legal. The existing chromatic-blur-on-dark-background rule is unchanged in semantics but now parses every color format. - text-shadow is checked wherever box-shadow was (browser DOM path with inherited-value dedupe, static engine via new textShadow cascade support, text engines). - The page-level text scan (regex engine + checkHtmlPatterns) is now a shared scanCssTextForGlow that resolves single-level var() refs against custom properties collected from the same text; unresolvable var() in a shadow color position is skipped, never guessed. Its dark-page heuristic accepts var()/oklch backgrounds but only when declared at root scope (body/html/:root or body inline style). - dark-glow keeps its id; registry name/description updated to cover both cases. Validated: three eval repro samples with oklch / var(--x) glows that previously produced zero findings now flag on the static CLI path; ten known-good largerun samples stay clean except one with genuine amber status-dot halos (0 0 12px oklch(.73 .17 65/.4)). Note: cli/engine/detect-antipatterns-browser.js and the extension detector are generated and still need 'node scripts/build-browser-detector.js' + 'node scripts/build-extension.js' once builds are unblocked. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 11:01:54 -07:00
Paul BakausandClaude Opus 4.6	8b93dfad5e	Merge color/motion/glow/layout fixture pairs into side-by-side files Each problem-space fixture is now a single file with two columns: left for cases that should flag, right for cases that should not. Matches the icon-tile-stack convention and makes browser-based visual review easier. The pass column proves that no false positives leak from look-alike patterns next to the real anti-patterns. Merged (4 pairs → 4 files) - color-should-{flag,pass}.html → color.html - motion-should-{flag,pass}.html → motion.html - glow-should-{flag,pass}.html → glow.html - layout-should-{flag,pass}.html → layout.html Left untouched - should-{flag,pass}.html — used by the CLI smoke tests in detect-antipatterns.test.js, which need a known-clean fixture for the exit-code-0 path. - typography-should-{flag,pass}.html — all three typography rules (overused-font, single-font, flat-type-hierarchy) are page-level and fundamentally can't share a page with their pass cases. Loading two font stacks suppresses single-font; varied sizes suppress flat-type- hierarchy. Documented in the test file. Test calibration - Hardcoded the jsdom finding counts (motion: 2 bounce + 2 layout- transition; glow: 1 dark-glow). Real browser sees more because jsdom doesn't fully apply class-based styles, but the pass-column count is reliably 0. Browser-verified all 4 fixtures show expected flag counts and zero pass-column false positives. Fixture chrome fixes - Sub-section labels (.col h3) now use #64748b instead of #94a3b8 so the fixture's own UI doesn't trigger low-contrast. glow.html got a CSS restructure into card-dark/card-light/card-medium variants so every text/background pairing meets WCAG AA. layout.html's "card with image" gradient changed from blue→purple to amber→rose so it doesn't trip ai-color-palette. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-06 23:31:29 -07:00

Author

SHA1

Message

Date

ac0416b655

Stop assuming white when a background cannot be read (#541 )

* Stop assuming white when a background cannot be read

Dark themes came back from a scan buried in low-contrast findings that
all claimed the light text sat on #ffffff. Two live runs against
impeccable.style produced 102 and 95 of them.

Two causes, both fixed here.

Parsing. Browsers keep the authored color space in getComputedStyle
output: oklch() stayed oklch, but color-mix results come back as
color(srgb 1.04 0.72 -0.21), wide-gamut authors get color(display-p3
...), and lch()/lab() survive verbatim. The parser read none of those, so
those surfaces registered as unset. parseGradientColors was worse: it
matched only rgba() and #hex, so a ground painted as
linear-gradient(oklch(...), oklch(...)) counted as a gradient with no
stops at all.

Guessing. When the ancestor walk ran out of readable color it returned
white, and on a body-level gradient it returned white without even
looking. Light copy on a lacquer-black page then measured 1.3:1 against a
canvas the visitor never sees.

resolveBackgroundInfo now separates three outcomes: a resolved surface, a
gradient the caller should fall back to stops for, and an unreadable
layer. The last one makes both color adapters skip their contrast checks
entirely. White survives in exactly one case, the one that earns it:
every layer up to the document root was genuinely transparent.

Color conversions moved to cli/engine/shared/color.mjs and gained lab,
lch, and color() for srgb, srgb-linear, and display-p3. Spaces outside
that set return null, which now routes to abstention rather than to a
color nobody painted. Every conversion is pinned against what Chrome
itself paints for the same string.

Rescanning impeccable.style: 102 low-contrast findings down to 30, none
of them on an invented white ground.

Assisted-by: Claude Code

* fix: address PR review bot findings on background resolution

- Treat a url() image layer stacked above a gradient as an occluding,
  unreadable surface: resolveBackgroundInfo now returns unresolved so the
  gradient-stop fallback never measures stops the image hides
  (greptile-apps finding, reproduced in Chrome).
- Route the glow and AI-palette DOM adapters through resolveBackgroundInfo
  so an unresolved surface makes them abstain instead of hunting gradient
  ancestors past an unreadable layer (Cursor Bugbot finding).
- Resolve background-color keywords jsdom hands through verbatim:
  inherit now reads as no-paint (the ancestor walk IS its resolution) and
  currentcolor substitutes the element's own computed text color instead
  of forcing an abstention (Copilot finding).
- Regression coverage in the dark-theme fixture for all three, asserted in
  both the jsdom and real-Chrome suites; browser detector regenerated.

AI-assisted: prepared with Claude Code at the maintainer's direction.

Co-Authored-By: Claude <noreply@anthropic.com>

* fix: keep zero-offset glow findings when the surface is unreadable

The browser glow adapter abstained from the whole element when
resolveBackgroundInfo reported an unreadable surface, which also dropped
zero-offset chromatic halo findings that do not depend on the background
at all. It now skips only the gradient hunt past the unreadable layer and
scores the halo tell against a null surface, matching what the static
loop already did. Fixture cases pin both sides: the halo over a url()
image ancestor flags in both engines, and an offset chromatic shadow on
the same unknown surface stays abstained.

Also hardens the currentcolor background substitution with the
parseColorResolved fallback used by the text-color path, and adds fixture
coverage proving tokenized currentcolor surfaces already resolve through
the static cascade (flag when knowable, abstain when the token is
undefined).

Addresses Cursor Bugbot review findings on PR #541.

AI-assisted-by: Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>

* fix: abstain on translucent gradients over images, drop phantom color-mix stops

Two follow-up review findings on the merge with main.

A gradient leading a url() layer was treated as a resolvable surface even
when its stops are translucent, so the glow and AI-palette hunts averaged
wash stops (a 20% black wash reads as pure black) while the real surface
blends with image pixels the engine cannot read. resolveBackgroundInfo now
marks gradient-over-image unresolved unless every readable stop of the
leading gradient is opaque, in which case the gradient provably covers the
image and remains the scorable surface.

parseGradientColorsModern predated this branch's parseGradientColors
rewrite: its second regex pass re-extracted color tokens nested inside
color-mix() stops that the shared parser already captures whole via
balanced-paren tokens, appending ingredient colors that are never painted.
The worst-case stop ratio then invented low-contrast findings against a
color nobody sees. The helper is removed; all callers use the shared
parser, which covers the modern syntaxes it existed for.

Fixture coverage pins both: the translucent-wash-over-image glow abstains
in both engines, an opaque gradient over an image still flags in the
browser, and the color-mix wash case stays clean in the static engine.
Each new assertion was verified to fail against the previous engine.

Addresses Greptile and Cursor Bugbot review findings on PR #541.

AI-assisted-by: Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>

2026-08-11 14:59:07 -04:00

Paul BakausandClaude Fable 5

0d72991bc8

detector: catch glow shadows in any color format, zero-offset halos on any background, and text-shadow glows

- parseAnyColor now covers oklab(), hsl()/hsla(), hwb(), and ~35 common
  named colors on top of rgb/rgba/hex/oklch, so checkGlow sees the color
  regardless of authoring format (Chrome preserves oklch() in computed
  styles, which the old rgba-only match silently passed).
- checkGlow gains a second tell: a zero-offset chromatic box/text-shadow
  with blur > 4px is flagged on ANY background (the halo pattern);
  achromatic zero-offset shadows and focus rings stay legal. The
  existing chromatic-blur-on-dark-background rule is unchanged in
  semantics but now parses every color format.
- text-shadow is checked wherever box-shadow was (browser DOM path with
  inherited-value dedupe, static engine via new textShadow cascade
  support, text engines).
- The page-level text scan (regex engine + checkHtmlPatterns) is now a
  shared scanCssTextForGlow that resolves single-level var() refs
  against custom properties collected from the same text; unresolvable
  var() in a shadow color position is skipped, never guessed. Its
  dark-page heuristic accepts var()/oklch backgrounds but only when
  declared at root scope (body/html/:root or body inline style).
- dark-glow keeps its id; registry name/description updated to cover
  both cases.

Validated: three eval repro samples with oklch / var(--x) glows that
previously produced zero findings now flag on the static CLI path; ten
known-good largerun samples stay clean except one with genuine amber
status-dot halos (0 0 12px oklch(.73 .17 65/.4)).

Note: cli/engine/detect-antipatterns-browser.js and the extension
detector are generated and still need 'node scripts/build-browser-detector.js'
+ 'node scripts/build-extension.js' once builds are unblocked.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-10 11:01:54 -07:00

Paul BakausandClaude Opus 4.6

8b93dfad5e

Merge color/motion/glow/layout fixture pairs into side-by-side files

Each problem-space fixture is now a single file with two columns: left
for cases that should flag, right for cases that should not. Matches the
icon-tile-stack convention and makes browser-based visual review easier.
The pass column proves that no false positives leak from look-alike
patterns next to the real anti-patterns.

Merged (4 pairs → 4 files)
- color-should-{flag,pass}.html → color.html
- motion-should-{flag,pass}.html → motion.html
- glow-should-{flag,pass}.html → glow.html
- layout-should-{flag,pass}.html → layout.html

Left untouched
- should-{flag,pass}.html — used by the CLI smoke tests in
  detect-antipatterns.test.js, which need a known-clean fixture for the
  exit-code-0 path.
- typography-should-{flag,pass}.html — all three typography rules
  (overused-font, single-font, flat-type-hierarchy) are page-level and
  fundamentally can't share a page with their pass cases. Loading two
  font stacks suppresses single-font; varied sizes suppress flat-type-
  hierarchy. Documented in the test file.

Test calibration
- Hardcoded the jsdom finding counts (motion: 2 bounce + 2 layout-
  transition; glow: 1 dark-glow). Real browser sees more because
  jsdom doesn't fully apply class-based styles, but the pass-column
  count is reliably 0. Browser-verified all 4 fixtures show expected
  flag counts and zero pass-column false positives.

Fixture chrome fixes
- Sub-section labels (.col h3) now use #64748b instead of #94a3b8 so
  the fixture's own UI doesn't trigger low-contrast. glow.html got a
  CSS restructure into card-dark/card-light/card-medium variants so
  every text/background pairing meets WCAG AA. layout.html's "card
  with image" gradient changed from blue→purple to amber→rose so it
  doesn't trip ai-color-palette.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-04-06 23:31:29 -07:00