8000 Scoped Web History API · Issue #2992 · whatwg/html · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

Scoped Web History API #2992

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.

Sign up for GitHub

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

Jump to bottom
Closed
dvoytenko opened this issue Sep 1, 2017 · 3 comments
Closed

Scoped Web History API #2992

dvoytenko opened this issue Sep 1, 2017 · 3 comments
Labels
topic: history

Comments

@dvoytenko
Copy link

I took a stub at outlining what the new Web History API could look like and what are the main challenges are using it: https://medium.com/@dvoytenko/new-web-history-api-91a1a21ff7b8

This is a bit of a tangent to #2710 which attempts to make a very minor and incremental change to the spec (or rather simply expose an existing datapoint). This document, however, re-envisions a bigger part of the spec. Most of Google web apps that I've worked closely with employ this kind of API.

To sum this approach up: the history.state currently is a bit too brittle. It's too easy to overwrite or null it out without different parts of the app knowing about this. What I propose is to change the API to set history state properties separately (one by one or in a group). This would make history state feel more like localStorage.setItem/getItem API. It will remove collisions and make state more reliable.

/cc @domenic, @natechapin, @spanicker, @RByers, @tbondwilkinson, @Yay295, @annevk
@dvoytenko dvoytenko mentioned this issue Sep 1, 2017
Closed
@Yay295
Copy link
Contributor
Yay295 commented Sep 1, 2017

It looks like you're trying to use the history state as both an object and a stack at the same time. I feel like this could become confusing on a webpage that heavily uses the history state. I'm also concerned that these changes may affect webpages using the current api. You mention making it feel more like localStorage, but why not make it exactly like localStorage (with the exception of having to stringify everything)? history.state and history.length could work the same as they do now, and there would be three new functions: history.setItem, history.getItem, and history.removeItem. Setting items this way would not affect history.state, so it wouldn't break anything.

Other potentially relevant discussions: #1454 #2985

@dvoytenko
Copy link
Author

@Yay295 this could go independent of current API which would be kept for backward compatibility. The exact shape of API is TBD, of course. The setItem, however, doesn't really represent two typical actions for history stack: push and replace. So, that has to be considered. Maybe it could be done via a separate argument or such.

@domenic
Copy link
Member
domenic commented Feb 2, 2021

It took us a few years, but now we're working together on WICG/proposals#20 :). Let's close this in favor of that effort.

@domenic domenic closed this as completed Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: history
Milestone
No milestone
Development

No branches or pull requests
4 participants
@domenic @dvoytenko @annevk @Yay295
0