Re: [csswg-drafts] [css-conditional-5] Anchor fragment scrolls should update scroll-state(scrolled) direction to stay consistent with scroll-padding (#13787)

I tried to work around this by making `scroll-padding-block-start `a dynamic value that mirrors the `scroll-state(scrolled)` query,  reducing it to zero when the header is hidden, restoring it when the header is visible. The attempt failed, and I think it's worth documenting why, as it strengthens the case for not only a spec, but maybe also a browser-level fix.

The approach was to move `scroll-padding-block-start` from `html` to `body`, then toggle it inside the existing `@container scroll-state(scrolled)` query:

```
@container scroll-state(scrolled: top) {
  .header { translate: 0 0; }
  body { scroll-padding-block-start: var(--header-height); }
}
@container scroll-state(scrolled: bottom) {
  .header { translate: 0 -100%; }
  body { scroll-padding-block-start: 0px; }
}
```

This hit two hard walls:

Chrome uses html's `scroll-padding` for viewport-level anchor navigation, not the body's. Setting it only on the body does not affect fragment scrolling, even though browsers propagate some properties (like overflow) from the body to the viewport.

A container cannot style itself. Since `html` must be the scroll-state container (`container-type: scroll-state`, because that's where the viewport scroll happens). There is no CSS path to toggle `scroll-padding-block-start` on `html` from within its own container query. Container queries only reach descendants.

I've put together a minimal demo illustrating the issue: [CodePen link](https://codepen.io/utilitybend/pen/JoRmNgb)

The status badge in the demo shows the current `scroll-state(scrolled)` value in real time. Clicking a TOC anchor link doesn't change it... It stays frozen in whatever state the last manual scroll left it. That's the bug made visible. And because there's no CSS escape hatch to work around it, the fix genuinely needs to happen at the engine level: anchor fragment scrolls need to set the last scroll direction for scroll-state queries.

I'm not sure what the best solution could be here. I know I'm not really providing one as well, but I think we can agree that this is not really ideal?  But that is all the info I have.

-- 
GitHub Notification of comment by brechtDR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13787#issuecomment-4222044691 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 10 April 2026 07:51:40 UTC