Comment by apitman
6 days ago
> I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position.
If your page is server-rendered, you get saved scroll position on refresh for free. One of many ways using JS for everything can subtly break things.
Still leaves the problem of not being able to simply send the current URL to someone else and know they'll see the same thing. Of course anchors can solve this, but not automatically
You probably don't want that most of the time, though. The time I'm most likely to send someone an article is once I've got to the end of it, but I don't want them to jump to the end of the article, I want them to start at the beginning again.
There are situations where you want to link to a specific part of a page, and for that anchors and text anchors work well. But in my experience it isn't the default behaviour that I want for most pages.
Chrome (at least?) solves this via Text Fragments[0] which are a pure client side thing and requires no server or site support.
This URI for example:
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Links to an instance of "The Referer" narrowed down via a start prefix ("downgrade:") and end suffix ("to origins").
These are used across Google I believe so many have probably seen them.
[0] https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
Scroll position doesn’t do this because it’s not portable between devices.
Even with JS, if it is classical synchronous JS it is much better than the modern blind push for async JS, which causes the browser to try to restore the position before the JS has actually created the content.
isn't there a way to instruct the browser to restore the position only after certain async thing?
I think the hack is to store html height/width locally and restore it as early as possible so the content will then load under the scrolled view
Also reminder that "refresh" is just a code word for "restart (and often redownload) the whole bloody app". It's funny how in web-world people so used to "refreshing" the apps and assume that it's a normal functionality (and not failure mode).
The web is similar to android, and unlike desktop apps, in that restarting the whole thing is meant to not lose (much) state
Actually it would be amazing if desktop applications were like this too, and we had a separate way to go back to the initial screen
Restoring state is just one of the features, that can be implemented in any app if needed, with all that baggage that comes with a feature – testing, maintaining, etc. It's just if desktop app becomes so broken/unresponsive, that the only way is to restart it – we consider it a bad experience and bad software. On web "restarting the app" is a normal daily activity when something goes wrong with state/layout/fields/forms, etc.
3 replies →
True