Summary

  • W3C's first public CSS Scroll Anchoring draft appeared on 11 February 2020. It described a browser that selects a node near the top of the visible reading area and adjusts the scroll position when content above it changes.
  • The 11 November 2020 draft clarified which nodes can become anchors and how anchoring interacts with scroll snapping. Publishers can use overflow-anchor: none when a scroller or subtree needs different behaviour.

The reader had found the interesting paragraph. Then the advertisement arrived late, pushed the article down and carried the paragraph out of sight. The browser had faithfully preserved a number: the distance scrolled from the top of the document. Faithfulness to that number was a rotten bargain for the person reading. A page can gain height above the viewport without the reader asking to move. The words under their eyes deserve a better claim on the screen than a coordinate does.

The W3C's first public draft of 11 February 2020 used this familiar irritation as its starting point. Its examples included a script inserting an ad iframe and an image without reserved dimensions loading over a slow connection. Both add material above the visible region. A site could reserve space in advance, and a conscientious publisher should. The draft also gave the browser a way to spare readers when that preparation failed: compensate for the added height by changing the scroll offset.

That sounds like an easy instruction until one asks what should stay still. A browser cannot simply pin the top of the document. It chooses an anchor node inside the scrolling box, generally deep in the document tree and close to the beginning of the visible reading region. The node is a reference point for what the reader is seeing. When content above it expands, the browser measures where that reference point was and where it is now. It queues a matching scroll adjustment. The late advertisement takes up room; the paragraph retains its place on the screen.

The draft's suppression window is part of the trick. The browser waits for an appropriate point in the rendering cycle to apply the queued change, so a flurry of layout work can be handled coherently. Anchoring also needs rules for choosing candidates. A box excluded from selection cannot become the point that holds the page steady. The algorithm is about the reader's visible context, not about treating every element as equally important.

The 11 November 2020 Working Draft sharpened that candidate language. Its changes section records new definitions of viable and priority candidates and a clearer relationship with scroll snapping. A snapped page already has an intended viewing position; anchoring must work within that constraint. The W3C publication history puts both drafts in 2020, with the February text as the first public version. The W3C announcement described the target in ordinary terms: changes above what a reader sees can make the page jump during reading.

Page authors still have a steering wheel. overflow-anchor starts at auto; none can take a scrolling box out of anchoring or exclude a subtree from candidate selection. That matters for interfaces that deliberately move content or manage their own scroll position. The browser supplies a default defence against surprise, and the publisher can mark the places where that default would fight the design. The choice is local to the relevant scroller and content, rather than a demand that every page behave alike.

The most useful image of scroll anchoring is a reader holding a finger against a line in a book while somebody slips a new page into the chapters above. The page count changes. The finger stays with the sentence. In 2020 the W3C drafts gave that small act a browser algorithm, a CSS escape hatch and a precise question: what on the screen should remain where the reader left it?