Direction-aware navigation with scroll-state(scrolled)

Direction-aware navigation with scroll-state(scrolled) is an emerging CSS pattern that makes it trivial to adapt UI to the user’s scroll direction without JavaScript. The new “scrolled” value in the scroll-state container-query feature lets authors query the direction of a container’s most‑recent relative scroll (values include none, top, bottom, left, right, block/inline/x/y and more), enabling effects such as hiding a er on downward scroll and revealing it on upward scroll.

Because scrolled is part of the CSS Conditional Rules Module Level 5 work, authors can express direction-aware navigation with pure CSS and enjoy snapshotting semantics that avoid layout cycles. That makes direction-aware navigation with scroll-state(scrolled) a performant, declarative option for many modern sites, especially when paired with standard performance and accessibility practices.

What the scrolled value is and why it matters

The scrolled feature is a new scroll-state container-query predicate documented in the W3C Working Draft for CSS Conditional Rules (Level 5) published 02 Jan 2026. It exposes a container’s most‑recent relative scroll direction so styles can react to whether the content was last scrolled up, down, left, or right (and other axis aliases such as block/inline/x/y).

Unlike ad-hoc JavaScript approaches, @container scroll-state(scrolled: bottom) gives you a declarative, CSS-first way to change layout or transforms when users scroll in a direction. That means simpler code and a reduced attack surface for scroll-driven UX patterns like hide-on-scroll ers, scroll shadows, and snap-aware highlights.

Because the value remembers the last scroll direction, designers can implement common patterns, hide on down, reveal on up, without writing scroll listeners, debouncing, or tracking state in JS. It’s a natural companion to container queries and the container-type model already in use by modern CSS.

Spec details and snapshot semantics

The CSS Conditional Rules Level 5 Working Draft documents scroll-state and explains the update/snapshot semantics used by the feature. To avoid runaway layout loops, scroll-state values are “snapshotted post-layout”: the user agent samples the container’s scroll-related state at a defined point and uses that snapshot for style application rather than continuously triggering new layouts.

These semantics are important for both correctness and performance. By decoupling state sampling from layout reflow, the spec helps ensure that using scroll-state doesn’t itself force continuous layout invalidation, one of the classic pitfalls of scroll-driven logic.

The draft also codifies a predictable model for authors: values can be none, top/bottom/left/right, or axis-based aliases. The Working Draft (02 Jan 2026) is the go-to reference for the exact rules and for explanations about how snapshotting avoids layout cycles when styles respond to scroll state.

Browser support and shipping timeline

Chromium’s Blink engine implemented scroll-state container queries early: Chrome 133 introduced the basics for CSS scroll-state queries (stuck, snapped, scrollable), and the Chrome team later posted an “Intent to Ship” specifically for @scroll-state(scrolled). The intent targeted shipping milestones around Chrome 144 for desktop, Android, and WebView.

Microsoft Edge followed Chromium’s lead. Edge’s Web Platform release notes list the scrolled feature as shipping in Edge 144, explicitly mentioning “The scrolled feature for scroll-state container queries” and even offering the hide-on-scroll er example in their notes. Blink’s tracking and intent messages also reference Web Platform Tests (WPT) coverage, and test results can be found on wpt.fyi.

As of 07/01/2026, Chromium-family browsers have shipped or are shipping scrolled (Chrome 144 / Edge 144). Other engines, Firefox and WebKit/Safari, were behind or not yet universally shipping scrolled at that time, so authors should verify live compatibility resources and use feature detection for production rollouts.

Practical demos and real-world examples

One practical and widely-cited demo is Bramus’s “hidey-bar” article and CodePen, which shows how @container scroll-state(scrolled: bottom) can hide a fixed er on scroll down and re-show it on scroll up. The demo sets { container-type: scroll-state } and uses a tiny rule like @container scroll-state(scrolled: bottom) { er { translate: 0 -100% } } to animate the er off-screen on downward scroll.

Chrome DevTools and Chrome Developers documentation introduced CSS scroll-state queries earlier (Chrome 133), highlighting use-cases such as styling based on stickiness, snap state, or scrollability. The scrolled predicate extends these ideas by remembering the last scroll direction, enabling direction-aware navigation patterns without JS.

Community posts and tutorials from authors like Una Kravets, LogRocket, and other practitioners (2024, 2026) provide dozens of patterns and code snippets. These pieces are useful references for using scrolled for navigation, scroll-snap highlighting, scroll-progress indicators, and showing shadows when scrollable.

Performance and animation guidance

When implementing hide/show navigation driven by scroll-state, prefer GPU-accelerated properties such as transform and opacity. Simple translate animations (e.g., transform: translateY(-100%)) are smooth and cheap to composite, while filters (blur) and heavy box-shadows can force expensive paint work and cause jank, especially on mobile devices.

Designers and engineers should combine scrolled-driven style changes with transition and will-change hints that encourage GPU compositing, and avoid layout-triggering properties. The community guidance and “no-jank” er writeups emphasize that a CSS-driven solution is only as good as the properties it animates.

Because scroll-state uses snapshot semantics and does not continuously force layouts, it already avoids many performance traps; pairing that with transform/opacity transitions gives a robust, smooth result for direction-aware navigation with scroll-state(scrolled).

Accessibility and progressive enhancement

Hiding navigation can be problematic for keyboard and assistive technology users if not implemented carefully. A common accessibility best practice is to prevent the er from hiding while it contains keyboard focus, e.g., er:not(:focus-within) can be used so interactive elements don’t disappear under the user’s hands.

Authors should also respect WCAG requirements such as Focus Not Obscured (WCAG 2.4.11 / 2.4.12) when using hide-on-scroll patterns. That means ensuring focusable controls remain visible and operable, and providing alternative ways to access navigation if it hides due to scroll state.

Progressive enhancement is essential: guard scrolled-driven CSS with feature detection like @supports (container-type: scroll-state) or offer graceful fallbacks (a visible/fixed er) and optional JS polyfills. This keeps the experience usable on non‑Chromium browsers and maintains accessibility across environments.

Testing, standards, and community guidance

Blink’s intent-to-ship and implementation messages reference Web Platform Tests (WPT) coverage for @scroll-state(scrolled), and the test results are traceable on wpt.fyi. Developers can consult WPT to understand expected behaviors and edge cases covered by the engine implementation.

Chrome team members like Adam Argyle have described scroll-state as “like container queries; but for stuck, snapped, and overflowing queries,” underscoring how scroll-state extends container queries to scroll-related conditions. That framing helps teams reason about when to reach for scrolled vs. a JS listener.

Multiple community articles (Una Kravets, LogRocket, Bramus, and more) offer practical advice, sample patterns, and warnings about cross-browser compatibility. Following these community patterns, plus keeping an eye on live compatibility tables, will help teams adopt direction-aware navigation with confidence.

Direction-aware navigation with scroll-state(scrolled) provides a declarative, performant way to react to scroll direction in CSS. When combined with transform-based animations, accessibility checks, and progressive enhancement, scrolled enables elegant hide/reveal navigation patterns without a lot of JavaScript.

Check compatibility before shipping, use @supports guards, and prefer simple transforms and focus-safe selectors (such as er:not(:focus-within)). With those precautions, scrolled is a powerful tool for modern, direction-aware UIs that play well with devices, performance budgets, and accessibility requirements.