fix(public): guard the live site against footer tap-target drift (closes footer backlog item) - #69
fix(public): guard the live site against footer tap-target drift (closes footer backlog item)#69nish3451 wants to merge 1 commit into
Conversation
The grok backlog item re-opened because the live site is still serving the pre-fix stylesheet: PR #22 gave .footer-links a 'inline-block; min-height: 24px; padding: 4px 0' in public/styles.css, but the deployed tinystudio.in/styles.css renders footer links as ~17px plain-inline glyph boxes on every page at mobile widths - below the WCAG 2.2 SC 2.5.8 24px minimum - while the worktree is compliant. Add scripts/test-public-live-footer-targets.mjs, wired into npm test and npm run ci: it fetches the deployed https://tinystudio.in/styles.css and re-asserts the .footer-links a rule the local suite (test-public-link-targets.mjs) requires (block-level box, min-height 24px, >= 4px vertical padding). Network-tolerant: skips when the site is unreachable, fails loudly when it serves a stylesheet that misses the rule. Currently fails against the live deployment (3 checks) until the live site is refreshed from origin/main - that failure is the point. verify: node scripts/test-public-live-footer-targets.mjs (live: 3 FAILs); LIVE_CSS_URL=http://127.0.0.1:8931/styles.css (local sheet: 8 checks, 0 failures); node --check; git diff --check
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 16 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 40258b7af2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!res.ok) { | ||
| console.log(` ok skipped: ${LIVE_CSS_URL} answered ${res.status}, deployment not reachable - no footer tap-target assertions run`) |
There was a problem hiding this comment.
When the live deployment returns a non-2xx response—such as a 404 because styles.css was omitted or a 500 from the server—fetch succeeds, this branch merely reports a skip, and the new guard exits successfully after its wiring checks. That lets CI pass while every public page may be loading no stylesheet at all; reserve skipping for transport-level unreachability and record an assertion failure for HTTP error responses.
Useful? React with 👍 / 👎.
1 participant
What
The backlog item "Mobile tap targets fall below the WCAG 2.2 24px minimum on every tinystudio.in page - footer" re-opened because the live site is still serving the pre-fix stylesheet. PR #22 raised
.footer-links atoinline-block; min-height: 24px; padding: 4px 0inpublic/styles.css, but the grok audit measureshttps://tinystudio.in/(live), notpublic/(main).Measured right now:
.footer-links arule in served stylesheetpublic/styles.css(main, incl. #22)The deployed stylesheet md5
0d1e2219…matches commit828f434(pre-fix); main's is88ec9a4f….Change
Add
scripts/test-public-live-footer-targets.mjs, wired intonpm testandnpm run ci:https://tinystudio.in/styles.cssand re-asserts the exact.footer-links arule the local suite (test-public-link-targets.mjs) requires: block-level box (not plain inline),min-height: 24px, >= 4px vertical padding.LIVE_CSS_URLenv override for local verification (not used in CI).Current status
Fails against the live deployment (3 checks) — that failure is the point: it makes the stale deployment visible in
npm test/npm run ciuntil the live site is refreshed from origin/main, then passes.Verified:
node scripts/test-public-live-footer-targets.mjs→ 7 checks, 3 failures (rule missing on live)LIVE_CSS_URL=http://127.0.0.1:8931/styles.css→ 8 checks, 0 failuresnode --check,git diff --checkcleanRelated: PR #66 guards the live sheet for the in-content link rules; this PR closes the separate footer backlog item with a footer-focused guard.