CSS Navigation Matching, Early Days

Actually just like the intent right here. Apply a mode when somebody navigates from one particular web page to a different. The concept being it’d make the sources for cross-document view transitions declarative in CSS relatively than managing that stuff in JavaScript.

Bramus has a hypothetical instance as this function is fleshed out:

• Outline the @location, i.e., the URLs concerned within the transition. Bramus makes use of @route however that seems to have modified since their publish.
• Question the @navigation between routes.
• Choose the factor that’s transitioned on every route.

So:

/* Outline the areas */
@location --contact-page {
  pathname: ("/contact");
}

@location --contact-confirmation {
  pathname: ("/contact/thanks");
}

That’s for after we know the actual pages we’re navigating from and to. There’s URL sample matching as nicely for the instances we don’t:

@location --article {
  sample: url-pattern("/article/:id");
}

/* 
  The place :id matches something two ranges deep like:
  /article/25
  /article/3785
  /article/no matter
*/

There are extra methods to outline the @location apart from the pathname and url-pattern descriptors. Like perhaps you’re attempting to match a hash-ed URL as an alternative, or a selected port or hostname. Apparently there’s protocol and search too, however truthfully, I’d should see examples and use circumstances to grasp when to make use of one descriptor over one other.

OK, so then now we have a solution to question the @navigation between areas utilizing the customized idents registered within the @location. If the navigation matches the 2 factors of navigation, then bingo.

/* Fireplace a transition when navigating between these two pages */
@navigation (from: --contact) and (to: --contact-confirmation) {
  /* Apply transition */
}

Fairly clear from and to situations there the place they’re related by an and key phrase.

One other solution to write it that’s a tad cleaner:

/* Fireplace a transition when navigating between these two pages */
@navigation (between: --contact and --contact-confirmation) {
  /* Apply transition */
}

Or, hey, we are able to fireplace this off when there’s not a match:

/* Fireplace a transition, however NOT when navigating between these two pages */
@navigation not (between: --contact and --contact-confirmation) {
  /* Apply transition */
}

There’s additionally an at key phrase to attach areas. The spec draft is obscure on this in the mean time, however Bramus demonstrates it like this:

@navigation (between: --home and --detail) {
  @navigation (at: --home) {
    /* Goal the clicked hyperlink's picture */
    :nav-source img {
      view-transition-name: picture;
    }
  }
}

I’ve gotta wrap my head round that. The way in which I learn it, it says, “once you’re navigating between --home and --detail and also you’re beginning ‘at’ --home, choose this factor and provides it this view transition identify.” In different phrases, it occurs on the very, very starting (or finish, I suppose) of the navigation between pages relatively than when it’s in progress. I feel. Please appropriate me.

And what about that :nav-source pseudo (which can be renamed to :navigation-source)? Once more, gotta wrap my head round all of it. However if I’m understanding proper, that’s to match the particular factor that triggers the transition. It’s the supply of the navigation, be it a hyperlink, picture, div, or no matter factor. I didn’t see something within the spec draft a few corresponding pseudo that matches the factor on the opposite facet of the transition — say, :goal? — however maybe there’s no clear use case for it.

Talking of pseudos, the spec defines one other one known as :link-to() that applies kinds to a linked factor that targets a sure location. Straight from the spec:

@location --homepage {
  sample: url-pattern("https://css-tricks.com/");
}

:link-to(--homepage) {
  font-weight: daring;
}

…which I think about matches a component in HTML like:

Again to Residence

…which I feel is so much like styling hyperlinks primarily based on their focused vacation spot? Possibly it’s extra a DX comfort when there’s already a declared location?

Couple notes

One factor I’m already not liking is that I doubt these options would work for a web site like CSS-Tips that has such a flat URL construction. Most of our URLs are a single stage deep. So, if I wish to match between a selected web page (/about) and any article (/article-url) there’s no solution to distinguish that route. However perhaps that claims one thing about the way in which URLs are designed round right here and they need to have extra construction. That’s not a trivial change although.

My pal Lee Meyer means that maybe it might be attainable to append a a parameter like ?weblog on URL to achieve URL sample matching superpowers.

Oh, and whereas I’m pondering of it, I might see a attainable use case the place you’d wish to apply sure kinds when navigating from one particular web page to a different. Like, perhaps you’re navigating between the homepage and an About web page and wish to model parts on the vacation spot web page primarily based on the place you’re coming from. Taking part in off the sooner instance from Bramus:

@navigation (between: --home and --article) {
  @navigation (at: --article) {
    /* Goal the .article-header factor  */
    .article-header {
      background-image: url('/path-to-image.webp');
    }
  }
}

I dunno. Looks as if there may very well be safety points with that?

And Preethi chimed in on the CSS-Tips Slack channel with what I feel is insightful suggestions:

It could’ve been nice if we had an at-rule for all knowledge infrastructures, much like @property for all property-value pairs, with configurations legitimate as per sort. We might’ve used it as an alternative of @color-profile, @position-try, and now @location.

So true when there’s so many new guidelines to study today. Something that lowers the educational curve is actually price contemplating.

There’s much more to this

You’ll wish to peruse the spec draft for your self to get deeper into the nitty-gritty of issues like navigating primarily based on navigation “sort” (e.g., again, ahead, reload) and navigation “phases” (e.g., loading, prepared, dedicated).

It’s so much to soak up. However so are view transitions as a complete.