Navigation API

[robwormald]

Request for position on an emerging web specification

• WebKittens who can provide input:

Information about the spec

• Spec Title: Navigation API
• Spec URL: https://wicg.github.io/navigation-api/
• GitHub repository: https://github.com/WICG/navigation-api

Design reviews and vendor positions

• TAG Design Review: App history API w3ctag/design-reviews#605
• Mozilla standards-positions issue: Navigation API mozilla/standards-positions#543

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:

Anything else we need to know

Linked explainers explain it well.

From a developer point of view this is a massive leap forward over the existing, kludgy solutions for routing / navigation interception. This is a difficult API to polyfill correctly, but a positive signal from WebKit would allow us to at least know there's a better future on the way.

From a framework implementer point of view, the biggest win with this API would allow us to properly centralize route handling, and perhaps begin to share / reuse more framework agnostic routing mechanisms. Most frameworks today must intercept anchor click events and effectively spoof navigation behavior, and this behavior is generally not compatible across various implementations, and requires a fair bit of (often brittle) code.

Angular : https://github.com/angular/angular/blob/main/packages/router/src/directives/router_link.ts#L396-L415
Vue: https://github.com/vuejs/router/blob/main/packages/router/src/RouterLink.ts#L138-L301
Remix: https://github.com/remix-run/react-router/blob/main/packages/react-router-dom/index.tsx#L270-L301

[domenic]

FYI the plan is to merge this into HTML; given Mozilla's support that work is mostly blocked on finishing whatwg/html#6315 first.

[bkardell]

It seems worth noting that whatwg/html#6315 mentioned by @domenic merged on Halloween 2022 and whatwg/html#8502 was created since and what to look at now?

[annevk]

Thank you for mentioning that @bkardell, that is indeed unclear. What we all need to review is whatwg/html#8502 which is rendered at https://whatpr.org/html/8502/nav-history-apis.html#navigation-api. (Both are linked from https://wicg.github.io/navigation-api/ but that was not linked from OP until I edited it just now.)

[domenic]

Hi folks, is there anything else I can do to help get WebKit's position on this API? Apart from the lack of clarity on multi-implementer interest, the spec PR is about ready to land, having gone through a few rounds of review.

[rd3k]

Is this blocked on anything in particular or just queued?

[lukewarlow]

https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-api The navigation API has been merged into the HTML spec just as an fyi.

[annevk]

Colleagues and I discussed this and as a result would like to mark this as "position: support" one week from now.

One unresolved question: why is it navigate(), but traverseTo()? Instead of navigateTo() & traverseTo() or navigate() & traverse().

[domenic]

One unresolved question: why is it navigate(), but traverseTo()? Instead of navigateTo() & traverseTo() or navigate() & traverse().

We chose traverseTo() instead of traverse() to indicate that, unlike history.go(), it's specifically going to a target passed as the argument, instead of moving by an offset.

We honestly weren't comparing navigate() and traverseTo() with each other much, and I can see how it's a bit strange when you look at them side-by-side. I tend to split the API mentally though: back(), forward(), traverseTo() in one corner, and navigate() in another.

Maybe another way of looking at it is, navigate(x) and navigateTo(x) should mean the same thing, so we pick the shorter/simpler one. Whereas traverse(x) and traverseTo(x) could arguably mean different things.

I hope this helps!