Ask HN: Why isn't bookmarking scroll position a thing? | Hacker News Reader

Ask HN: Why isn't bookmarking scroll position a thing?

32 points1290783520216 comments

A regular problem I have with the web is that I will find an interesting article and start reading only to later see how tiny the scroll bar is on the page and realise I don't have the time to finish in that moment.

Now it seems like my only option is to bookmark the entire page and later scroll up and down trying to find my spot.

This seems odd considering how ubiquitous the concept of bookmarks has been for centuries.

It is common to be able to store locations in modern formats like video and music and be prompted whether to restore location or restart but not older formats like text.

Bulletin boards often track the last page you visited but not which comments you've scrolled past. Although this is different to reading a single large body of text.

It's made even worse by the fact that most pages load many trackers, some of which even track user scrolling, but that this isn't utilised for the readers experience.

In many cases scroll position is saved such as via the back button in a browser. But this isn't made available for bookmarking.

Google Chrome does now let you link to a text fragment. But this becomes quite fiddly to use as a bookmarking tool. The "share" option doesn't have an add to or update bookmark option suggesting this isn't its intended purpose. We're just lucky they've accidentally given us a tool we can also use for bookmarking with a couple of extra steps.

Even if it would be difficult for browsers to implement due to shifting screen dimensions, it seems some major text heavy websites like medium, Wikipedia or substack could implement it. It seems like it could even be a feature "do you want to finish reading X?" But as far as I can tell nobody ever has.

Is anyone on HN implementing something like this on their site? Or tried in the past?

Name Anchors has been a thing in HTML for a very long time (at least since HTML 2.0 spec [1], if not earlier).

  <a name="myanchor"><h3>Things to do</h3></a>

If the CMS supports name anchors, you can just bookmark it as

  https://example.com/foo.html#myanchor

Of course, authors are not mandated to follow named anchors for their document fragments, so this is just a best practice.

[1]: https://www.w3.org/MarkUp/html-spec/html-spec_7.html#SEC7.4

Post JS build pipelines and web packers, most element names and classes are just minified garbage.

Sadly most web devs don't give a damn about accessibility anymore :(

Especially not in the React and Angular based ecosystems and toolchains. Server-side rendering was popular for a while, but even then the generated HTML codes were pretty useless for A11y focussed products.

You don’t need named anchors to accomplish the goal of URL fragments. ID attribute values on any element accomplish the same goal.

Yes. The name/id choice recommendation has been evolving since the original HTML spec. For modern browsers (in 2023), you are right about the id attribute. Some very old browsers needed the name anchors.

I'm sorry this isn't a complete answer but I came here to mention named anchors - I love those things but they're not used as much as they could be.

While looking up a reference for that I came across this https://developer.mozilla.org/en-US/docs/Web/Text_fragments which, as far as I can tell from a quick reading, is the feature you're describing Chrome as having but it seems is a little more widely implemented than that https://developer.mozilla.org/en-US/docs/Web/Text_fragments#... .

Oh interesting I didn't know it was a standard.

I only use Firefox and Chrome and it's missing in Firefox.

There is an extension for Firefox: https://addons.mozilla.org/en-US/firefox/addon/link-to-text-...

(Funny that I can find an extension for that but not the bookmarking I was looking for.)

A discussion about it is on GitHub: https://github.com/mozilla/standards-positions/issues/194

And there's some discussions on Reddit which are currently dead and I didn't bother using archive.org to read them.

As you may already know, the high-level answer is that our UI paradigm largely comes straight from the original release of the Macintosh and only a few improvements have stuck and become widely diffused since then, while indeed other parts of the paradigm have been rotting away. One part of it—and this one, to be fair, is shared with GNU Emacs—is that things like undo and save only apply to the content of documents themselves while elements of view status like document position are treated as largely ephemeral. We're just lucky that saving URLs with fragments sometimes works. The ePub Canonical Fragment Identifiers thing https://idpf.org/epub/linking/cfi/epub-cfi.html is interesting but I don't think it's ever been widely supported even in ebooks let alone ported to the Web or other document formats.

I wonder if lacking this behaviour by default extra incentivizes ephemeral reads and many pages. Though maybe there isn't much motivation for implementing it to begin with because the web ecosystem already heavily incentives this situation so sites don't consider it. It also seems like the most dependable split reading experience of a single webpage is to just offline save because pages online can easily change and go dead on you over time. And so maybe that is why apps for saving the web end up being where features like saving reading position or highlighting are instead implemented.

For comments, I partially dealt with the issue by writing a bookmarklet that highlights the latest comments and jumps to the next one on the page with each click of it. It works pretty well for finding current activity, cutting across deep threads later in a discussions timeline, and seeing what I wouldn't have earlier.

If you're using Chrome, there's Scroll To Text Fragment, and it works on any page regardless of its markup.

https://chromestatus.com/feature/4733392803332096

Doing this manually is tedious, but a browser extension would make it super easy.

The right-click context menu on selected text has an option to copy the url with that text fragment highlighted (and scrolled to).

My biggest issue with the web is that I can't get to a specific state with a specific URL. What is a URL really for, if a webpage shows me modals and their state is not encoded in the URL?

The cool thing about the web is that I can easily copy and share a URL and whoever I share it with can quickly look at the same thing. But in modern SPA-land it has become harder and harder.

The thing is, the DOM has a consistent state so I'm sure the browser could generate some hash of the current state even if the modern web developer can't figure it out.

I made 1paragraph[1], a web app / chrome extension that solves this problem. It's a reader view and read-it-later app in one, and it saves and restores scroll position.

[1]: https://1paragraph.app/

if you're lucky and the article was written in a competent CMS that uses named anchors on titles (or other elements), you could use those to jump directly to e.g. that heading, like example.com/article/something.html#footnotes

Instapaper keeps track, so you could save long articles and read them on it

I think most people probably just scroll down to about where they left of reading and pick up from there.

It doesn’t seem to be a problem, really.

named anchors (at least) are so good when you're telling someone else to go and look at part of a document. It's the difference between "read this section http://example.com/foo.html#bar" and "go to http://example.com/foo.html and then scroll down to the heading which reads 'All about Bar'"

Reply on news.ycombinator.com