If you inspect the book that is linked above it is literally made up of several hundred webpages. So the reader is effectively transitioning from one webpage to another. And the history api is meant exactly for this use case!
Edit: Here's the definition. A Superbook [1] is a stack of simple webpages, just like a book.
Again, each page on that book is an independent link that you're navigating to.
I'm afraid you're just saying things because you want to say things and do not really understand what is going on with the history api in there. ;-)
Another way to think of it is that a web page is one document, and so is a book. The history stack is a list of visited documents. If the book should be treated as a collection of documents, then it should be structured that way.
I don't think there's a good solution to online books that are presented like that, but I like how the Kindle app works: following a link or jumping ahead in the book adds a history entry (with the in-app back button), but just turning the page doesn't.
Websites are not books. No one will read Harry Potter and Prisoner of Azkaban like a website or a news article.
Books are also not files, going strictly by first principles.
> Another way to think of it is that a web page is one document, and so is a book.
One page is document. Multiple pages clipped together is a document. Website is a document. Video is document. Audio is document. Book is document. Manuscript is document. You are a living breathing document of your own life!
Everything is a document!
But history api on the web exposes useful methods and properties that let you navigate back and forth through the user's session history, and manipulate the contents of the history stack. It does not talk about the unit of transition within a session being a document. It stacks only webpages on the history api in the positive direction of time just like reading through a book. And that's what is implemented.