Repository navigation
Row-stripe side-tab: three gaps Greptile found after #1133/#1156 #1164
Description
Greptile flagged these on the 4.7.1 release PR (#1159), whose diff briefly included main's row-stripe code from #1133 and #1156. They aren't verified yet; each needs a fixture to confirm.
- Token lookup crosses apps (
crates/detect/src/project_tokens.rs:50):project_rootpicks the Git root before the nearestpackage.json, so separate apps in one checkout share one token map. Ifapps/a/tokens.cssandapps/b/tokens.cssdefine--dangerdifferently, the first file wins when scanning a component in app B. !importanton box-shadow is lost (crates/core/src/checks/row_stripe.rs:555): the shadow check usesparse_css_decl_block, which drops!importantand keeps the last value, sotd.is-error { box-shadow: none !important; box-shadow: inset 3px 0 0 red; }reportsside-tabalthough the browser draws no shadow. The border parser already reads priority.- URL scans miss border stripes on cells (
crates/core/src/browser/element_checks.rs:529): a visibletdwithborder-left: 3px solid #c2410cinsidetr[data-state=failed]reports through the text and static HTML paths but not the browser path. Needs the row-border case in the browser path and a URL test over the existing fixture.
(Issue opened by Claude Code on behalf of @pbakaus.)
Activity
anirudhqwerty commentedon Oct 24, 2026
@pbakaus I reproduced item 2 only on current main,
936867543ac2576920d663cc9803597f6044f3ac, without changing production code.The fixture contains real status cells in a table. Chrome computes
box-shadow: nonefor this cell, butdetect_html_sourcereportstd.is-error — inset box-shadow 3px stripe on a row or cell (left edge). The normal inset stripe and a genuinely important inset stripe both correctly report. The individual tests use the sametd.is-errorselector and matching table body, isolating declaration priority from selector matching.Root cause:
parse_css_decl_blockstrips!importantand unconditionally replaces each property's value.scan_css_text_for_row_stripeuses that last value for the shadow check. #1156 preserves priority for borders, but this shadow path remains unchanged. I found no overlapping open PR.Regression-only diff · GitHub Actions evidence
none.cargo test --locked -p impeccable-core row_stripe --lib: 3 passed.side_accent_radiustests plus the two positive controls, excluding the new expected failures: 17 passed.cargo test --locked -p impeccable-html --test side_accent_radius row_shadow_priority -- --nocapture: 2 passed, 2 failed as expected. The exact reset case incorrectly reports, and the combined fixture reports three stripes instead of two. The workflow explicitly expects the failing regression step; it does not indicate that the regression passed.Proposed scope: resolve the winning
box-shadowdeclaration by importance, then source order, beforeinset_stripe; reuse the existing priority-marker handling and leave the shared parser contract, border handling, and items 1/3 unchanged.Would you approve a focused PR for item 2 with this scope? No production fix or PR has been created.
AI disclosure: Codex assisted with this investigation and authored the regression tests; verification ran on GitHub Actions, including the real Chrome cascade check.