A stylesheet that knows how you got there
A new Cascading Style Sheets (CSS) module working its way through the World Wide Web Consortium (W3C) would let a single stylesheet behave differently depending on which page a visitor is on and which page they came from, all without a line of JavaScript. The proposal, called CSS Navigation Matching, has an Editor's Draft dated August 10, 2026, edited by Google engineers L. David Baron and Noam Rosenthal, and it can currently only be tested in Chrome Canary behind an experimental flag.
The idea first went in front of the CSS Working Group in January 2026 and picked up developer feedback at the CSS Day conference in June. Coverage of the current draft syntax has picked up through August, most notably from developer Bramus Van Damme and from CSS-Tricks, pointing to renewed momentum on a feature that is still visibly in flux.
Naming a URL so CSS can reference it
The centerpiece of the proposal is a new at-rule, currently written as @location, that gives a name to a URL pattern so the rest of the stylesheet can refer to it. An early version of the proposal from late July used the name @route for the same idea; by the current spec draft it has been renamed to @location, a reminder that none of this syntax is settled yet. A location declaration looks like this:
@location --contact-page {
pathname: url-pattern("/contact");
}
Once a location has a name, two more pieces of syntax become useful. A :link-to() pseudo-class lets a stylesheet style any link element differently depending on which named location it points to:
:link-to(--contact-page) {
font-weight: bold;
}
And a new conditional at-rule, @navigation, matches an actual transition between two named locations, letting a stylesheet apply rules only when the user is moving from one specific page to another:
@navigation (from: --home) and (to: --contact-page) {
a[href="/contact"] { color: red; }
}
A fourth piece, a :nav-source pseudo-class, targets the specific element that triggered a navigation, mirroring the sourceElement property already available on the NavigateEvent object in the browser's Navigation application programming interface (API). The current spec draft indicates this pseudo-class may still be renamed to :navigation-source before anything ships.
The real target is view transitions
The stated goal in the specification is not just link styling. It is to make cross-document View Transitions, the browser feature that animates smoothly between full page loads, configurable declaratively in CSS instead of requiring a developer to write JavaScript that intercepts every navigation event to decide how a transition should look. Today, building a custom transition between two specific pages generally means listening for navigation events in script and applying transition names conditionally. Navigation Matching would let a developer express the same logic as plain CSS rules tied to named locations, in principle making transition behavior easier to reason about and to override.
Where this actually stands
None of this is close to shippable. It exists only in Chrome Canary, gated behind the "Experimental Web Platform Features" flag, which is the browser's holding area for ideas that have not committed to a stable release. The rename from @route to @location within a few weeks shows the syntax is still being actively negotiated inside the CSS Working Group, and a working group draft is a starting point for standardization, not a promise that the feature will ship in its current form or on any particular timeline. Firefox and Safari have not indicated a position on the proposal.
What it means for developers
There is nothing to build against yet, and treating any of this syntax as stable would be premature given the rename already visible in the draft history. What is worth tracking is the direction: browser vendors are pushing more navigation and transition logic out of JavaScript and into declarative CSS, following the same pattern that made animations, container queries, and now view transitions progressively less dependent on script. If Navigation Matching or something like it ships, sites that currently hand-roll page transition logic in JavaScript would gain a simpler, more inspectable way to express the same behavior directly in a stylesheet. For now, the practical step is to watch the spec's evolution rather than to plan around any specific syntax shown today.
