New history event proposal

[frehner]

preface: this was first introduced here whatwg/html#5562 and at time of writing this message has a bit of positive "reaction" feedback (for a proposal, anyway 😄 ). Since this is a new place for proposals, I'm reopening the issue here. The original text is copy/pasted below, in hopes that 1) I'm doing this in the right spot, and 2) that it gains some traction. Please let me know if I've done something wrong - I'm open to feedback

Proposal

Add an event called statechange or historychange that will fire on any change to the history stack, whether that be through the browser's back button, or window.history.pushState or other methods.

This proposed event would be similar to popstate, except that it would fire on all route changes regardless of the source, much like hashchange fires on all hash changes regardless of the source.

Current Problems

hashchange events allowed javascript router libraries (e.g. React Router, vue-router) to easily respond to any routing event when the application is using hash routing.

However, with the HTML5 History API, there is no equivalent event that javascript routers can listen to.

This means that routers have the following limitations/problems:

• They assume that they're the only Router that exists on the page - Routers require all code to call into it whenever making a URL change
• Users cannot call window.history.pushState directly and must only use the Router's custom methods
• Third party libraries that may want to change the URL or cause a Router to update have a difficult time since they can't call native APIs

References:

remix-run/react-router#6304

Example

window.addEventListener('historychange', (event) => {
  console.log('changed')
})

history.pushState(null, null, '/path')  // logs "changed"
location.hash = "sub" // logs "changed"

Side notes

This was created in collaboration with @joeldenning

[MelSumner]

It seems like this could be helpful for accessibility purposes too- see w3c/aria#1353

[frehner]

@MelSumner if there is anything that I can update/change in this proposal to make it better for accessibility, please let me know and I would love to do it.

[MelSumner]

@frehner sounds great! I think we have a few options:

• you could read through the the aria issue and pull whatever you wanted from that into this
• we could coordinate via email to work on integrating the a11y needs here
• I could post suggestions via comments here (that might get a bit noisy, though?)

What do you think?

[frehner]

@frehner sounds great! I think we have a few options:

• you could read through the the aria issue and pull whatever you wanted from that into this
• we could coordinate via email to work on integrating the a11y needs here
• I could post suggestions via comments here (that might get a bit noisy, though?)

What do you think?

I read over the linked issue and it all sounds good. Do you think that this proposal would cover the case you have written here?

Another potential solution is some sort of new event hook- something that indicates that a semantic navigation event has occurred. (Vaguely, imagine something like pushState but also have a second parameter with a promise that resolves with a DOM node.) Both frameworks and assistive technology could use this event to indicate/recognize new content.

Though I don't fully understand the resolved-promise-with-a-dom-node part - would that serve as a way of indicating to assistive technologies what should be focused once the navigation has completed?

In any case, I think that posting comments here would be a good place for the conversation to happen, for this reason: though I've made this proposal, I'm not officially affiliated with the WICG/WHATWG and I have no influence nor power to get anything done here (which is why this proposal - both here and the identical one I made in the whatwg repo - has sat dormant).

So I would hate for you to have to put in the work of emailing me only for that knowledge to be lost when the actual powers-that-be hopefully come by one day and discuss this proposal. Whereas if you comment here, then your knowledge/insight is available to those that will work on it.

If that's ok with you?

[MelSumner]

@frehner sounds good!

[domenic]

Hey @frehner and @MelSumner! As I mentioned to @frehner on Twitter, toward the end of last year I got pulled in to an effort to give web developers better tools for dealing with the history stack, especially in single-page applications. In particular, some of us at Google think that the problem goes deeper than just the popstate event being bad: the entire window.history API is subpar.

I've publicized the work in #20, and would love your support in that thread. I think the currententrychange event in the app history API proposal encompasses the use cases from your original post, and I'd love you to help double-check that and maybe send a pull request with more examples. (Currently I have "TODO: Add a non-analytics examples, similar to how people use popstate today.")

You'd probably also be interested in other parts of the proposal, e.g. the navigate event and its standardized notion of a single-page app navigation (as discussed in this section) might help with the accessibility issues discussed in w3c/aria#1353. (I'll also comment over there.)

Let me know what you think, and in #20, let the WICG chairs know if you think the app history proposal is worthy of WICG incubation!