181–190 of 532 posts
I understand this is vague on purpose but wish there was more detail. E.g., if I am running a game in a webgl canvas and "back button" has meaning within the game UI which I implement via history states, is my page now going to be demoted? This article doesn't answer that at all.
Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…
Also www.reddit.com is/was doing the same back button hijacking. From google.com visiting a post, then clicking back and you would find yourself on Reddit general feed instead of back to Google.
[1] At least, I hope it's a bug.
Earlier quoted context omitted.
The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page. This feels like a reasonable counter-measure.
> It's also a great way to store state so that a user may bookmark or link something directly. Can you unpack this please? AFAIK history stack is not preserved in the URL, therefore it cannot be preserved in a bookmark or a shared link.
https://developer.mozilla.org/en-US/docs/Web/API/History/pus...
> The new history entry's URL. Note that the browser won't attempt to load this URL after a call to pushState(), but it may attempt to load the URL later, for instance, after the user restarts the browser.
Earlier quoted context omitted.
Could you provide some examples of the hacks you're referring to?
State management, URL fragment management, reimplementing basic controls... One that I hate the most is that they first reimplement tabular display with a soup of divs, then because this is slow as a dog, they implement virtualized display, which means they now need to reimplement scrolling, and because this obviously breaks CTRL+F, they end up piling endless hacks to fix that - assuming they bother at all. The resul…
For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables.
There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.
I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.
And to be clear, I'm not saying that people building SPAs when all they needed was a page showing 10,000 rows of static data isn't a problem. It's just a people problem, not an SPA problem.
Ok, you can start with LinkedIn, I'll wait... If you are wondering how it works. You get a link from LinkedIn, it's from an email or just a post someone shared. You click on it, the URL loads, and you read the post. When you click the back button, you aren't taken back to wherever you came from. Instead, your LinkedIn feed loads. How did it happen? When you landed on the first link, the URL is replaced with the homep…
The problem is, there are two conceptions of the back button, and the browser only implements one. One conception is "take me back to the previous screen I was on", one is "take me one level up the hierarchy." They're often but not always the same. Mac Finder is a perfect example of a program correctly implementing the two. If you're deep in some folder and then press cmd+win+l to go to ~/Downloads, cmd+up will get y…
Why not fix this at the browser level? E.g. long or double click on back button = go to previous non-javascript-affected page (I mean by that: last page navigated to in the classical sense, ignoring dynamic histories altered by js and dynamic content)
if i'm on page C and go back, page B will take me to page C again. i think this is more about techincal incompetence rather than malicious intent, but still annoying.
Earlier quoted context omitted.
Please explain the legitimate uses. Not once I have ever encountered a website that does something useful by modifying the behavior of my browsing history.
Any single page application, such as YouTube, Gmail, or discord. It lets persistent content (videos) or connections (chat) persist while emulating a pagenated browsing experience. When it's done right you don't notice it at all.
Earlier quoted context omitted.
The problem is, there are two conceptions of the back button, and the browser only implements one. One conception is "take me back to the previous screen I was on", one is "take me one level up the hierarchy." They're often but not always the same. Mac Finder is a perfect example of a program correctly implementing the two. If you're deep in some folder and then press cmd+win+l to go to ~/Downloads, cmd+up will get y…
> The problem is, there are two conceptions of the back button, and the browser only implements one. In web browsers, there is only one concept. There is no concept of "up one level in the heirarchy". If you want that make your own button in your website.