Safari 27 Scroll Anchoring: Keep Your Place When Content Loads Above
In Safari 27 the paragraph stays put when images load above it, but scrollTop changes and a scroll event fires with no user input. What does that do to your own scroll logic?
- Safari 27 enables scroll anchoring by default to preserve visible content when material loads above it.
- Keeping the same content in view may change scrollTop and produce scroll events.
- Lists with their own position management should test that interaction and opt out only where necessary.
Content can load above the reader without pushing the paragraph away
Safari 27 adds scroll anchoring without requiring an opt-in from the site. When material arrives above the visible content, the browser adjusts scrolling to keep the reader's place. WebKit's release announcement gives images, ads and comments as examples.
This matters for pages that continue assembling after someone starts reading. The document can become taller without forcing the person to find the same paragraph again. It is a change in Safari 27; older supported versions still need their own testing.
Preserving the view can require changing the scroll offset
The goal is visual continuity, not an unchanged scrollTop value. As MDN explains, the browser compensates for movement outside the viewport. A paragraph pushed farther down the document needs a different scroll offset to remain at the same screen position.
For a practical comparison, record which paragraph is visible and where it sits before inserting content. Checking only whether the scroll number changed can label a successful adjustment as a failure.
The scroll anchoring specification also says that adjustments generate scroll events. Code that treats every such event as a user gesture, or writes a new position in response, needs to account for browser-generated movement.
Choose a narrow boundary for application-managed scrolling
overflow-anchor defaults to auto. A component whose position is managed by application code can opt out with none. For example:
.manually-managed-list {
overflow-anchor: none;
}Start with the component that needs control. Disabling anchoring for the whole page also removes its benefit from ordinary reading content. MDN identifies scroll listeners that mishandle compensating movement as a reason to investigate this interaction.
An auto declaration on an ordinary descendant cannot undo an ancestor's exclusion for the same scrolling box. There is a useful distinction in the specification: a nested scroll container can anchor its own scrolling box unless it too is explicitly opted out. Identify the element that actually scrolls before changing the rule.
Separate insertion, correction code and style changes
Anchoring does not freeze every movement. Changes to computed height, position or transform along the path from the anchor to the scrolling element can suppress an adjustment. Inspect those changes alongside the content insertion.
A useful diagnostic comparison runs the same insertion with application correction enabled and disabled, while tracking the visible paragraph. Record the browser version and any none rules as well. This narrows down which mechanism needs attention without assuming that two corrections always conflict.
Momentum and virtualized lists add another variable. A TanStack Virtual report describes losing the reading position in Safari 18.4 when history arrives during a bounce at the top. It concerns an older Safari release and a bounce state, so an upgrade check should repeat that interaction as well as a stationary insertion.
Keep the default for ordinary content, and exercise real insertion flows in components that control their own position. Remove an existing workaround only after checking the browsers and interaction states it was intended to support.