Safe Sticky Positioning

Make sticky headers, bars, and panels behave consistently and stop fighting each other.

moderate User Experience

What it adds

One shared approach to sticky elements, with a single source of truth for offsets and reserved space.

What your agent is told to do

1
Inventory every element meant to stay put while its surroundings scroll — page headers, table header rows, section titles, filter bars, side panels, action bars — and route them all through one shared arrangement instead of the several that exist. The bottom-edge case is owned by Sticky Action Bar; this brief owns the mechanism and the offset arithmetic it draws on.
2
Keep a single source of truth for stacked offsets, so a header, a sub-header, and a sticky table row each know the measured height of what sits above them. A hardcoded pixel offset per screen guarantees drift the first time the header changes height.
3
Reserve the space a sticky element will occupy before it detaches, so nothing jumps at the moment it changes behaviour and no content is left hidden underneath it.
4
Below the narrow breakpoint, decide per element whether it stays, collapses to a smaller form, or unsticks entirely. On a short screen three stuck bars leave almost no room for the content they are framing.
5
Do not apply sticky positioning inside an ancestor that clips or scrolls its own overflow — the element will either be trapped or disappear. Detect that case during the audit and either fix the ancestor or move the element out of it.

Edge cases it handles

An ancestor with hidden or scrolling overflow silently breaks sticky positioning, and the symptom — an element that stays put on one page and scrolls away on another — is easy to misdiagnose as a styling problem.
Without reserved space the page shifts by the element's height at the instant it sticks, which moves whatever the user was about to click.
Two sticky elements that both claim the top edge will overlap. Offsets have to derive from measured heights so that a wrapping header or an incident banner pushes everything below it down.
On a short viewport sticky chrome can consume most of the usable height, so measure the real visible area rather than assuming the window height, particularly with an on-screen keyboard open.
Anchor navigation and in-page links must offset their scroll target by the sticky height, or the heading being jumped to lands underneath the header.
Keyboard focus moving to an element just below a sticky header must not leave that element obscured; scrolling into view has to account for the occluded strip.
A sticky element with a transparent or blurred background shows content sliding beneath it, which needs a deliberate treatment rather than being discovered in review.

Definition of done

All sticky elements share one mechanism and one source of offsets.
Stacked sticky elements never overlap, whatever height the header takes.
Nothing shifts when an element transitions into or out of its stuck state.
No sticky element sits inside an ancestor that clips or scrolls its overflow.
Sticky behaviour is defined explicitly for narrow and for short viewports.
Anchor links and focus scrolling land below the sticky chrome rather than under it.
The feature matches the existing design system.
No existing functionality is broken.

Related features

Feedback Widget

Interactive Transcript

Reschedule and Cancel Links

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.