-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New history event proposal #6
Comments
It seems like this could be helpful for accessibility purposes too- see w3c/aria#1353 |
@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. |
@frehner sounds great! I think we have a few options:
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?
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? |
@frehner sounds good! |
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 I've publicized the work in #20, and would love your support in that thread. I think the You'd probably also be interested in other parts of the proposal, e.g. the 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! |
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
orhistorychange
that will fire on any change to the history stack, whether that be through the browser's back button, orwindow.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 likehashchange
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:
window.history.pushState
directly and must only use the Router's custom methodsReferences:
remix-run/react-router#6304
Example
Side notes
This was created in collaboration with @joeldenning
The text was updated successfully, but these errors were encountered: