[css-view-transitions-2][css-conditionals] Exposing navigation/route matching

[noamr]

Following from a past discussion around navigation-matching for view-transitions in #8925, there is an emerging proposal to expose "routes" (URL patterns) directly in the platform, and allow CSS to respond to them.

See route matching explainer, as well as WICG/declarative-partial-updates#46 for discussing the route-map syntax.

The proposal currently is to have a <script type=routemap> that gives names to different URL(pattern)s, and then allowing to select them via CSS, for example:

<script type=routemap>
 { "article": "/article/:id" }
</script>

<style>
@route article {
  section[name=article] {
    display: block;
  }
}
</style>

Opening this issue for an introductory presentation at the F2F and see if this kind of direction resonates.

[bramus]

Looking up some of my old VT syntax explorations, I have this snippet where I define the routes in CSS.

@routes {
  --articles: urlpattern('/articles');
  --article: urlpattern('/articles/:article_id');
}

Seems like a nice alternative to the proposed script type=routemap for defining the possible routes.

(The usage of urlpattern() in CSS also came up in #10975 (comment))

[bramus]

Oh, I was also reminded of @document which was removed from css-conditional (and has partial support in Firefox).

@document url("https://www.example.com/")
{
  h1 {
    color: green;
  }
}

[noamr]

Looking up some of my old VT syntax explorations, I have this snippet where I define the routes in CSS.

@routes {
--articles: urlpattern('/articles');
--article: urlpattern('/articles/:article_id');
}
Seems like a nice alternative to the proposed script type=routemap for defining the possible routes.

(The usage of urlpattern() in CSS also came up in #10975 (comment))

We are likely to use this route definition for things other than styling though... The styling use case is perhaps the first one but not the only one. For example it would allow defining whether a navigation between two routes should create a new navigation entry by default.

[css-meeting-bot]

The CSS Working Group just discussed Exposing navigation/route matching.

The full IRC log of that discussion

<ydaniv> noamr: presenting route matching, something new, more informative
<ydaniv> ... to start prototyping, get feedback and reactions to guide it
<ydaniv> ... in a few months get to something resolvable
<ydaniv> ... showing 5 issues quickly, that bring this issue up
<ydaniv> ... starting with VTs for dialogs
<ydaniv> ... we discussed before navigation matchings, between different URLs, between different pages, you want different transitions
<ydaniv> ... another conversation about going from a list view into details view
<ydaniv> ... a major use-case for VTs
<ydaniv> ... from another side you have a desire to do things ppl do on SPAs and apps, allow more primitves to do that OOTB
<ydaniv> ... more outside of CSS, allow more user-agency for these kind of transitions
<ydaniv> ... try finding things that can help in these cases
<ydaniv> ... a few things in that direction, the one we'll discuss today is a "route" to be a DOM primitive
<ydaniv> ... to be able to declare a route as a web platform primitive, with a pattern, like a regexp superset, allow authors to give them names
<ydaniv> ... and specify rules about going between them
<ydaniv> ... then how they tie into CSS
<ydaniv> ... not specific to VTs
<ydaniv> ... dealing with routes like they're an attribute of the DOM
<emilio> q+
<kbabbitt> q+
<ydaniv> ... then in CSS be able to relate to named routes to specify rules inside them
<astearns> q+ fantasai
<ydaniv> ... then in VTs be able to specify different animations between different routes
<ydaniv> ... style link in particular ways, like if its a link we came from, or navigating to
<SebastianZ> q+
<astearns> ack emilio
<ntim> @-moz-document
<ydaniv> emilio: the @route stuff, FF used to have @-moz-document to specify patterns
<ydaniv> ... it feels weird to have that extra layer
<ydaniv> noamr: it's a option to have path names, URLs works better in JSON
<ydaniv> ... specific URL matching we tried to experiment with, URL patterns are not exactly strings
<ydaniv> emilio: you can do some glob stuff, <missed>
<ydaniv> noamr: it's going to be exposed to scripts for matchMedia
<ydaniv> ... allows basic stuff of navigation without scripting
<ydaniv> ... no need to do pushState stuff
<ydaniv> ... potentially other stuff in the future, but clearly not a CSS feature, just that CSS is the first use-case
<ydaniv> emilio: assuming you have to make all the routes CSS-valid
<astearns> ack kbabbitt
<ydaniv> noamr: probably going to be in quotes
<ydaniv> kbabbitt: when I saw the @route(home) was confusing, seems like from A to B
<ydaniv> ... to emilio's points, author is defining states, they may want to have something called initial and it's a reserved keyword
<astearns> ack fantasai
<ydaniv> fantasai1: had the same confusion
<emilio> q+
<ydaniv> ... is it location classes, and then have routes from-to location
<kbabbitt> +1 fantasai1
<ydaniv> ... so mayabe have more sense to have @location
<ydaniv> ... also, do we want to have JSON here? or have CSS syntax to be easier to write for most ppl
<ydaniv> ... can have a canonical JSON as well for LLM
<ydaniv> ,,, I think the idea to be able to name locations and reference them is very useful
<kizu> q+
<ydaniv> ... so you're use-cases make sense
<ydaniv> ... I think emilio's point that this should be a URL pattern makes sense, ability to put in a literal <missed>
<emilio> `@media document-url("/foo/:bar") {` seems potentially nice?
<ydaniv> noamr: a route is usually a path connected with rules
<ydaniv> ... all things that exist today are used with the name route
<ydaniv> ... the JSON stuff is also trying very hard to not be noval
<ydaniv> ... it's taken from import maps, currently common, follows that script, doesn't feel like a CSS feature
<ydaniv> fantasai1: I think CSS syntax is reasonable
<ydaniv> noamr: it's a good option, open question
<ydaniv> fantasai1: there was previously an XML syntax, very verbose, very complex, very generic
<ydaniv> ... JSON is a very generic syntax like XML, it's necessary, but CSS has more sophisticated syntax that allows to do more, be more readable
<fantasai1> s/very complex//
<ydaniv> noamr: open to discussion. Having inline URLs inside CSS is things we can consider
<astearns> ack SebastianZ
<fantasai1> s/XML syntax/XML schema language, RelaxNG, which had an XML-based syntax that was/
<ydaniv> SebastianZ: I think it's reasoable to split from CSS
<ydaniv> ... and can be reused in both CSS and JS
<ydaniv> ... the include in @import prelude, to import based on a group?
<fantasai1> s/very generic/because it re-used XML which is very generic; but it also had a "compact" syntax, which was designed for humans and tailored to the language, and was much much easier to read and write/
<ydaniv> noamr: I think import already has conditions, right?
<ydaniv> SebastianZ: yes, but import based on rout
<ydaniv> s/rout/route/
<astearns> ack emilio
<ydaniv> emilio: it's an option to add it to conditions, but you'll get a FOUC
<fantasai1> We have window.location, so I think "location" is a better word than "route" here.
<ydaniv> ... a reason to add it to @media you'll get a lot of other stuff for free
<bramus> q?
<bramus> q+
<ydaniv> ... that may also give you the import thing
<ydaniv> ... probably @media will be a better option
<ydaniv> noamr: one thing that could affect the future is to able to use pseudo-classes rather than @-rules
<flackr> q+ to ask relation to :target
<ydaniv> ... it's more of nested thing, it's more like lang, which can be nested
<ydaniv> ... but no objection to any suggestion
<astearns> ack kizu
<ydaniv> kizu: really interesting, can be used with forms
<ydaniv> ... however, under security and privacy considerations, can be used with query params and be used to extract stuff from there
<ydaniv> noamr: so far out internal sec team hasn't come with issues, maybe just with nested routes, but those aren't designed yet
<ydaniv> ... we may need to take more care there
<ydaniv> ... the routes themselves include query params, things like values that go into forms would ordinarily go into the query params and these are not exposed to CSS
<ydaniv> ... but not everything is final security wise
<ydaniv> bramus: I like it, needed it before. Regarding naming, there was route-location, there are many things today called routes, maybe we should adopt this terminology
<ydaniv> ... there's a need to allowing rules of whether this was from A to B
<SebastianZ> q+
<astearns> ack bramus
<astearns> ack flackr
<Zakim> flackr, you wanted to ask relation to :target
<ydaniv> flackr: the simple use-case, the :target pseudo, can be used with route to make things visible/not
<ydaniv> ... to be able to use :target with in routes
<ydaniv> noamr: the problem with :target is that it is an exact match, and they may be other things that are not exactly matched
<ydaniv> ... another problem is that it directly goes with links, and you have to put :has() on everything, it's a perf hotspot
<bramus> s/... there's a need to allowing rules of whether this was from A to B/... there's a need to allowing rules of whether this was from A to B. Example use case is conditionally enable View Transitions using the view-transition at-rule based on the navigation source or target.
<ydaniv> ... if you actually have a link that's linking to the current route then I want to style it with :target
<ydaniv> fantasai1: isn't it where you land on a link?
<ydaniv> noamr: it's the link
<ydaniv> fantasai1: not what you're trying to do here
<ydaniv> flackr: if this is an extension of :target, maybe reuse that name?
<ydaniv> noamr: I think we can use the name where it makes sense, it's not necessarily about elements, there's sometimes no element in there
<ydaniv> fantasai1: what is the :navigation-target?
<ydaniv> noamr: it goes to a route that matches a link you clicked
<ydaniv> fantasai1: so while you're navigating there, there's a link that points there and you want to point to it?
<ydaniv> noamr: yes
<ydaniv> ... if you have next/previous and/or number
<ydaniv> ... or you want to go to expand view
<astearns> ack SebastianZ
<ydaniv> ... link in history navigation, it's like an expansion to...
<ydaniv> SebastianZ: also wanted to ask, you had the id of the article, is it in your proposed syntax?
<ydaniv> noamr: yes it's in there
<ydaniv> SebastianZ: if you want to style based on parts inside that syntax?
<ydaniv> noamr: didn't go that far yet, you can check for a parameter and do something specific
<ydaniv> astearns: shall we conclude here?
<ydaniv> noamr: yes, no need to resolve on anything

[noamr]

Adding a few principles in conjunction with WICG/declarative-partial-updates#46 and with the F2F minutes:

• routes can be queried combined with their parameters
• routes are potentially scoped, and their conditionals should reflect that
• Routes can either match the current state (whether stationary or navigation), or be reflected a link

So, suggesting something along the following:

<route-name> = <ident>
<route-with-params> = <<route-name>> ['[' <<route-param>> [ '*' | '~' | '$' ]? '=' <<route-param-value>> ']']*
<route-affinity> = at | with | from | to
<route-selector> = <<route-affinity>>? [ <<route-with-param>> || <<url>> ]
<route-query> = <<route-selector>>#

@route(<route-query>) { /* document-scoped route */ }
#some-element:route(<route-query>) { /* a matching route is in the element's scope */ }
:link(<route-query>) { /* this link is to a particular route */ }

Some more specifics:

• and/or/not etc. can be used like in media/container queries
• The navigation-based routes are valid when from when the navigation starts, and until the navigation ends (all handler callbacks are called), and with the "current" URL changing when the navigation commits.

[bramus]

Some quick questions/feedback:

• I see <route-with-params> defined, but it’s not used anywhere in the snippet. Do you have an example?
• I see you’re trying to capture “a route matches” and “a navigation { from x / to y / from x to y }” both under @route. Maybe this should be split up into @route and @navigation?
• I don’t understand the explanation “a matching route is in the element's scope” for the #some-element:route(<route-query>) example.
• Shouldn’t :link(<route-query>) be :link([<route-name> || <route-name-with-params>])?
• I still would like to be able to define routes in just CSS, withou the need for the routemap script.

[noamr]

Some quick questions/feedback:

• I see <route-with-params> defined, but it’s not used anywhere in the snippet. Do you have an example?

Oops, fixed

• I see you’re trying to capture “a route matches” and “a navigation { from x / to y / from x to y }” both under @route. Maybe this should be split up into @route and @navigation?

It's something to consider! Though the thing is that a route itself can be a "navigation". A route is a rule, not a particular current URL.

• I don’t understand the explanation “a matching route is in the element's scope” for the #some-element:route(<route-query>) example.

It's explained here. Route rules can be either document or element scoped, kind of like language/direction.

So the following would work:

<section id=dashboard>
   <script type=routemap>[{"name": "main", "route": "/dashboard"}]</script>
</section>
<section id=settings>
   <script type=routemap>[{"name": "main", "route": "/settings"}]</script>
</section>

An element styled something:route(main) would work differently in the dashboard section and in the settings section because they have separate route maps.

This allows defining how URLs map to UI in a more local way without having to think about the whole document's namespace.

Note: like with view-transitions, planning to have this as an enhancement after we get document-scoped routing done, but wanted the design to take that into account.

• Shouldn’t :link(<route-query>) be :link([<route-name> || <route-name-with-params>])?

I fixed that, yes.

• I still would like to be able to define routes in just CSS, withou the need for the routemap script.

OK.