Fix the queue chip fade falling short of the right edge #30

2026-10-03T07:33:46Z

niklas commented

2026-10-03 07:33:46 +00:00

Reported against v0.35.0: the scroll-fade on the queue filter chips ends slightly before the actual screen edge, instead of reaching it.

Cause: .chips-fade was position: sticky as the last flex item of the row it's overlaying. Its sticky offset (right: -1px) interacted with the row's gap and the item's own margin-left: -24px, landing it short of the true edge — visibly, a sliver of the next chip's rounded edge stayed poking out past where the fade should have covered it.

Fix: switched to the simpler, more robust pattern for an edge-fade on a scrolling row — position: absolute against a position: relative; overflow: auto parent, not sticky. An absolutely positioned child resolves against the parent's own (non-scrolling) box, so it stays flush with the real edge at any scroll position, without the flex-gap/margin interaction that caused this.

Verified visually, not just by re-reading the CSS: no browser automation tool is available in this environment, but Chromium's headless_shell binary is on the machine, so I built a standalone reproduction of both the old and new .chips/.chip/.chips-fade CSS and screenshotted each at a 390px mobile width.

Old (sticky): the last visible chip's label is cut off by the viewport, and the next chip's rounded left edge is visible poking out past the fade — the exact bug reported.
New (absolute): the row fades cleanly to the page background right at the edge, no sliver of the next chip visible.

Local gate (fmt lint test helm-lint, including -race) is green.

Reported against v0.35.0: the scroll-fade on the queue filter chips ends slightly before the actual screen edge, instead of reaching it. Cause: `.chips-fade` was `position: sticky` as the last flex item of the row it's overlaying. Its sticky offset (`right: -1px`) interacted with the row's `gap` and the item's own `margin-left: -24px`, landing it short of the true edge — visibly, a sliver of the next chip's rounded edge stayed poking out past where the fade should have covered it. Fix: switched to the simpler, more robust pattern for an edge-fade on a scrolling row — `position: absolute` against a `position: relative; overflow: auto` parent, not `sticky`. An absolutely positioned child resolves against the parent's own (non-scrolling) box, so it stays flush with the real edge at any scroll position, without the flex-gap/margin interaction that caused this. **Verified visually**, not just by re-reading the CSS: no browser automation tool is available in this environment, but Chromium's `headless_shell` binary is on the machine, so I built a standalone reproduction of both the old and new `.chips`/`.chip`/`.chips-fade` CSS and screenshotted each at a 390px mobile width. - Old (sticky): the last visible chip's label is cut off by the viewport, and the next chip's rounded left edge is visible poking out past the fade — the exact bug reported. - New (absolute): the row fades cleanly to the page background right at the edge, no sliver of the next chip visible. Local gate (`fmt lint test helm-lint`, including `-race`) is green.

niklas added 1 commit 2026-10-03 07:33:46 +00:00

Fix the queue chip fade falling short of the right edge

CI / chart (pull_request) Successful in 1s

Details

CI / security (pull_request) Successful in 16s

Details

CI / test (pull_request) Successful in 5m13s

Details

710521a73c

position: sticky, as a flex item of the row it's pinning itself
against, interacted with that row's gap and its own negative margin in
a way that landed it short of the true edge -- visibly, a sliver of
the next chip stayed poking out past where the fade should have
covered it, which is the "ends before the screen edge" bug reported
against the release.

Replaced with the simpler, better-supported pattern for this: an
absolutely positioned overlay against a position:relative, overflow:
auto parent. Unlike a sticky descendant, an absolutely positioned one
is resolved against the parent's own (non-scrolling) box, so it stays
flush with the real edge regardless of scroll position, without the
flex-gap/margin interaction that caused this.

Verified visually: a standalone reproduction of both versions,
screenshotted with Chromium's headless_shell (no browser automation
tool available in this environment, but the binary's right there) --
the old version shows the next chip's edge peeking past the fade, the
new one doesn't.

🤖 Generated with [Claude Code](https://claude.ai/code)

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

niklas merged commit 43beda9a30 into main

2026-10-03 07:36:12 +00:00

niklas deleted branch fix-chips-fade-edge

2026-10-03 07:36:13 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: niklas/terdut-server#30