Skip to content

refactor: give the frozen right header band its own width slack - #1275

Merged
6pac merged 1 commit into
masterfrom
refactor/frozen-header-band-width
Aug 10, 2026
Merged

refactor: give the frozen right header band its own width slack#1275
6pac merged 1 commit into
masterfrom
refactor/frozen-header-band-width

Conversation

@6pac-ai

@6pac-ai 6pac-ai commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Warning

Stacked on #1274 (this PR's base branch is refactor/headers-width-slack) — it uses the HEADER_WIDTH_SLACK constant and the scroll-sync pin spec introduced there. Please merge #1274 first; GitHub will retarget this PR to master when that branch is deleted.

Resolves Q15 from the quirks triage (discussion #1247): under a left freeze, the right header band's width was cumulativeheadersWidthR = max(sumR, viewportW) + headersWidthL — sizing the right band to include the entire left band's width for no stated reason.

Why it survived until now (the load-bearing part)

Every header band is built with left: -1000px on the columns container plus an injected .slick-header-column { left: 1000px; } rule, so each band's width must include 1000px of shift compensation or its columns overflow it. In the frozen path, the right band's compensation was delivered through headersWidthL (= sumL + slack) — which is why the triage classified Q15 as unknown-business-path and why a naive "drop the + headersWidthL" would genuinely break the right band (clipped header columns, scroll clamping short at full right scroll — the pin spec fails exactly there on the naive version).

The borrowed sumL on top of that compensation was the phantom part.

The change

One line: the right band now carries its own compensation —

this.headersWidthR = Math.max(this.headersWidthR, this.viewportW) + HEADER_WIDTH_SLACK;

The right header container gets sumL narrower (inert — it is clipped), and its post-offset extent becomes max(sumR + gutter, viewportW): exactly the regime the unfrozen band has always run in (its +1000 was likewise consumed by the -1000px offset all along). The frozen right band now matches that long-standing contract instead of exceeding it by an arbitrary, frozen-band-width-dependent margin.

This supersedes the triage's "defer normalization to the branch rework" position — the deferral existed because there was no safety net, and #1274's pin spec is that net.

Validation

  • headers-width-scroll-sync.cy.ts (from refactor: single scrollbar add and named slack in getHeadersWidth #1274) passes unchanged — its frozen-grid checks (header scroll range covers body range, header reaches the body scrollLeft at full right scroll with no clamping, last-column header/cell alignment) exercise exactly this contract.
  • example-frozen-columns-and-rows.cy.ts green (8/8).
  • Full cypress suite: all specs passed — 652 tests, 650 passing, 2 pre-existing skips (3m46s).

(With this and #1274, every actionable width-arithmetic item from discussion #1247 is resolved; Q14's shift-compensation slack is now named and documented, and the Q15 entry in the tracking notes moves from keep-as-is to normalized.)

🤖 Generated with Claude Code

Base automatically changed from refactor/headers-width-slack to master August 10, 2026 06:10
Under a left freeze the right band's width borrowed the entire left band
(headersWidthL) - Q15 in discussion #1247. The load-bearing part of that
borrow was only the 1000px shift compensation embedded in it (every
header band is offset left:-1000px with columns shifted +1000px back),
so the right band now carries HEADER_WIDTH_SLACK directly and drops the
phantom left-band width. Its post-offset extent becomes
max(sumR + gutter, viewportW) - the same contract the unfrozen band has
always run in.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@6pac-ai
6pac-ai force-pushed the refactor/frozen-header-band-width branch from be77698 to 48db230 Compare August 10, 2026 06:20
@6pac
6pac merged commit 354cce4 into master Aug 10, 2026
3 checks passed
@6pac
6pac deleted the refactor/frozen-header-band-width branch August 10, 2026 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants