Hi @noamr, thank you for the review request. I note the mention of accessible alternatives in the draft note in the spec. There isn't an 'accessibility considerations' section in the explainer or spec, though. Could you let us know your thoughts on accessibility? (If you could add such a section to the spec, or explainer, that'd be great.)

Hi @noamr, thank you for the review request. I note the mention of accessible alternatives in the draft note in the spec. There isn't an 'accessibility considerations' section in the explainer or spec, though. Could you let us know your thoughts on accessibility? (If you could add such a section to the spec, or explainer, that'd be great.)

Added: https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#accessibility-considerations

This spec is adjacent to a few a11y features/considerations such as indicating the "current link" with aria-current, or indicating "loading" with aria-busy, but we don't see atm how these should impact the spec, if at all.

If TAG or anyone else thinks that there is some oversight around a11y, we'd love to hear!

Thanks @noamr for posting this. I had some mostly surface-level comments/questions.

• Which aspects of the feature, if any, will function for cross-origin navigations? Is this intended to be a same-origin-only feature like view transitions or are there cross-origin use cases we should be thinking about?
• I think the non-react HTML example in https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#framework-routers is missing have a spinner element matching :active-navigation(to --home) + spinner { opacity: 100%; }
• Every instance of @location shown in the explainer has base-url: document. It'd be helpful to show a case where it's useful to set base-url to something else. If this is not common, maybe that should be a default rather than something that needs to be specified in every @location block.
• In general more examples would be helpful, especially examples of how this will be used together with view transitions.
• In https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#url-matching, the code block has from, to, between, and at, but the explanation after has with instead of between. Which should be used here? The meaning of between seems self-explanatory but I'm not sure how with or at should be used even after reading the explanatory text a few times.
• On https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#navigation-type-matching, what's the difference between @navigation (history: navigate) { ... } and @navigation (history: traverse) { ... }? In the spec https://drafts.csswg.org/css-navigation-1/#typedef-navigation-type-keyword only has traverse so maybe navigate shouldn't be there?
• The explainer has some formatting issues for example in https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#link-matching and a few other places where there are literal ### which I think are meant to be subsection headers.
• Is there a consistent way to define a @location rule that always matches "the current URL", outside of a navigation, without hardcoding any paths? That seems like it'd be useful e.g. in tandem with a:link-to so that any link that'd trigger a refresh is styled differently.

Thanks @noamr for posting this. I had some mostly surface-level comments/questions.

Thanks for the review! Are you planning to provide some more deeper opinion about the approach of providing navigation info directly to css? That would be the kind of review I was hoping for from TAG.

• Which aspects of the feature, if any, will function for cross-origin navigations? Is this intended to be a same-origin-only feature like view transitions or are there cross-origin use cases we should be thinking about?

This feature mirrors the navigation API, which fires events also for cross origin navs.

So yes, cross origin navigation can affect styling.

A use case can be styling links to a particular origin or showing an exit animation if a cross origin navigation is initiated.

• I think the non-react HTML example in https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#framework-routers is missing have a spinner element matching :active-navigation(to --home) + spinner { opacity: 100%; }

Thanks, will get that fixed!

• Every instance of @location shown in the explainer has base-url: document. It'd be helpful to show a case where it's useful to set base-url to something else. If this is not common, maybe that should be a default rather than something that needs to be specified in every @location block.

Yes, there are ongoing discussions about how base URL should work.

• In general more examples would be helpful, especially examples of how this will be used together with view transitions.
• In https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#url-matching, the code block has from, to, between, and at, but the explanation after has with instead of between. Which should be used here? The meaning of between seems self-explanatory but I'm not sure how with or at should be used even after reading the explanatory text a few times.

Right, for now we are not specing 'with'. Cc @bramus for examples.

• On https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#navigation-type-matching, what's the difference between @navigation (history: navigate) { ... } and @navigation (history: traverse) { ... }? In the spec https://drafts.csswg.org/css-navigation-1/#typedef-navigation-type-keyword only has traverse so maybe navigate shouldn't be there?

It felt like push/replace is not so much a styling concern but it's debatable.

• The explainer has some formatting issues for example in https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#link-matching and a few other places where there are literal ### which I think are meant to be subsection headers.
• Is there a consistent way to define a @location rule that always matches "the current URL", outside of a navigation, without hardcoding any paths? That seems like it'd be useful e.g. in tandem with a:link-to so that any link that'd trigger a refresh is styled differently.

That could be a good keyword to have.