Skip to content

Adjust z-index layering for plan area and sprite animation#592

Closed
backnotprop wants to merge 2 commits intomainfrom
claude/fix-tatter-layering-SBS9r
Closed

Adjust z-index layering for plan area and sprite animation#592
backnotprop wants to merge 2 commits intomainfrom
claude/fix-tatter-layering-SBS9r

Conversation

@backnotprop
Copy link
Copy Markdown
Owner

Summary

Updated z-index values to fix the stacking order of UI components, ensuring the plan area and sprite animation display correctly relative to other elements.

Key Changes

  • App.tsx: Increased plan area z-index from z-10 to z-20 to ensure it appears above other overlapping elements
  • TaterSpriteRunning.tsx: Updated sprite animation z-index from 5 to 15 and clarified its positioning in the stacking context
    • Now positioned above sidebar tabs and resize handles (z-10)
    • But below the plan area stack (z-20)
    • Updated comment to reflect the new z-index hierarchy

Implementation Details

These changes establish a clearer z-index hierarchy:

  • Sidebar elements: z-10
  • Sprite animation: z-15
  • Plan area: z-20

This ensures proper visual layering and prevents the sprite animation from appearing above the plan document content.

https://claude.ai/code/session_019Q3pp1qUN52e76PqpHY6mg

claude added 2 commits April 19, 2026 04:31
Two recent PRs bumped ResizeHandle (#354) and the collapsed SidebarTabs
rail (#519) to z-10, which put them on the same stacking level as the
plan area wrapper — and crucially above the running tater sprite (z-5).
The sprite was meant to sit above the sidebar rail/resize handles but
below the plan card; now it was pinned behind all of them.

Shift the plan area wrapper up to z-20 and the sprite to z-15 so:
  - sidebar tabs / resize handles (z-10) stay below the sprite
  - the sprite runs in front of them across the bottom of the viewport
  - the plan card stacking context (z-20) still paints over the sprite

https://claude.ai/code/session_019Q3pp1qUN52e76PqpHY6mg
The previous commit diagnosed this wrong. The real regression came from
PR #509 (Zed-style overlay scrollbars), which wraps <main> in
overlayscrollbars. The library's CSS applies
`position: relative; z-index: 0` to its `[data-overlayscrollbars-padding]`
and `[data-overlayscrollbars-viewport]` wrappers (see
overlayscrollbars.css:206/214), which creates a stacking context INSIDE
<main>. That traps the plan's `z-10`/`z-50` inside it: from the outer
content wrapper's perspective, the entire plan subtree paints at
effective `z=0`, so the tater at `z-5` ends up on top of it.

Bumping planAreaRef doesn't help — it's already trapped inside the
library's z-0 stacking context, so its value only changes layering
WITHIN that bubble. What has to change is the layer the whole bubble
paints at in the outer context, i.e. the <main> host itself.

Give the OverlayScrollArea <main> `relative z-20`, which makes it a
stacking context at z=20 in the outer wrapper. Keep the sprite at z-15
so it still paints above the z-10 sidebar rail / resize handles but
below <main>. Revert planAreaRef back to `relative z-10` — its bump
was a no-op given the trap.

https://claude.ai/code/session_019Q3pp1qUN52e76PqpHY6mg
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