WHATWG on 2026-02-23

15:02	<vhilla>	dbaron: Do you remember why we have step 2 of https://html.spec.whatwg.org/#auto-directionality? I wonder whether https://github.com/whatwg/html/pull/9880 should have removed that. Firefox had two bugs around that recently and I can't come up of real-world implications.
15:05	<vhilla>	Specifically, slotted content inherits directionality through the light tree default content isn't relevant for step 2 Since PR 9880, ancestors of `<slot>` depend on the host's directionality. Afaik, step 2 only matters to the `:dir` selector.
16:47	<Sam Sneddon [:gsnedders]>	Can someone explain to me at all the rationale of what is and isn't a navigation? Because, e.g., `pushState` fires the `navigate` event (with `NavigationDestination.sameDocument` being `true`) but at the same time doesn't do anything else that I'd consider even a fragment navigation to consist of? No `popstate`, no `hashchange`, no scroll to fragment, etc. Is the intent of the Navigation API to expose anything that changes history state, rather than anything which actually does a navigation or a fragment navigation?
16:48	jjaschke	summons farre
16:50	farre	arrives!
16:51	<farre>	Bottom line is more or less anything that adds, removes or changes a session history entry is a navigation
16:54	<farre>	easiest is to trace backwards from https://html.spec.whatwg.org/#inner-navigate-event-firing-algorithm.
16:54	<farre>	that's a boring answer though :/
17:31	<Andreu Botella>	hey, does anyone know if pr-preview is broken, or if i'm doing anything on https://github.com/whatwg/webidl/pull/1568 and https://github.com/whatwg/dom/pull/1451 that's breaking it?
18:31	<Sam Sneddon [:gsnedders]>	I mean that will tell me what is, but won't explain the rationale of it. 😛 It just seems surprising to have a "navigate event" which doesn't correspond to the "navigate" algorithm of the spec.
18:50	<Psychpsyo>	My understanding (which could be wrong) is that the navigation API kinda just changes the history and current URL, but nothing beyond that, so that single-page apps can pretend to navigate around and hook up to the browser's back/forwards buttons while not actually navigating around. An actual navigation to `/foo/bar` would go to a different document, while navigating there with the navigation API stays on the same document and just pretends to have navigated without actually doing so. (serving up new content for the new location is up to the code that called pushState, not the browser itself)
19:05	<farre>	Ish, calling intercept on a navigate event changes the navigation to a same document navigation, which is roughly what you're saying.
19:08	<farre>	But the navigate methods on the navigation object are just wrapped regular navigations that return promises
19:10	<farre>	It's NavigateEvent.intercept that does the new stuff
19:13	<farre>	And it's all a rather intricate way of doing SPA
21:41	<Noam Rosenthal>	Indeed the "navigate" algorithm in the spec (not to be confused with `navigation.navigate()`) is a subset of what counts as a navigation in the navigation API. A lot of the rationale is described in the Navigation API README but LLMs are probably better at summarising it than myself :)