Unrelated, but flipping through that book is one of the few times I wished for a UI that did not keep pages in your your history. Flip through a few pages and try to click back.
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.
I should have shared the Cover [1] instead of the Book itself. Then it'd have opened on a new tab.
[1] https://bubblin.io/cover/a-108-verses-of-the-gita-by-swami-b...
This balances the history-pollution, pagination, and link-based reference needs.
(There's been some playing with the notion of linking content within web pages by the specific text or string. such as, say, "There's been some playing". With word-based ngrams, 4--5 word sequences are strongly likely to be unique within a work, save for cliched phrases or idioms.)
I am aware about the views held by the older generation of developers on this topic; most of those unix heads (especially on this forum) are desktop thinkers and end up buying physical books on latest software themselves. ;-)
With paginated navigation.
On desktop, scrolling using page-oriented controls (spacebar or page-up / page-down) isn't a terrible online reading experience. The fact that paper-oriented presentation remains so abysmally poor at less than ~4k retina display resolution remains a real friction for reading.
On mobile devices, touch + scroll itself becomes quite bad. High-speed emissive displays at least handle the refresh requirements, but make precise navigation all but impossible.
E-ink, portrait mode, and pagination, aren't quite the paper experience, but are reasonably close.
The variant I mentioned in my earlier comment works reasonably well for destkop reading. I find that scrolling through up to about 20--30 pages worth of printed material without a break is tolerable. Beyond that, the scrolling (and imprecision of placement) becomes tedious.
(I've, um ... accidentally ... created book-length HTML documents and actually read them. It's doable, but it's far from the ideal.)
Scrolling vertically is orthogonal to the reading direction. This makes us lose track of scanning head (leading word/sentence) on the content easily. Goes against the grain of our saccadic perception kinda of.
A horizontal flipping transition however, with line-tracking over the text (orphan/widow handling) is the most comfortable book reading experience since it is only intermittently animating—when moving forward to the next page, and connects with the forward flow of storytelling along a groove that our eyes can keep track of.
IMO, page flipping is THE native control of a book and it cannot be dropped off the standards just like that!
I recently read a paper on why an iridescent screen of an iPad or a smartphone is better for the human eyes than a reflective surface of electronic paper like E-ink.
Flux of light.
Intensity or flux is the only parameter that matters to the health of our eyes, and that’s something one could control only with an IPS panel type of screen. Since an e-ink relies on ambient lighting fwiw, low illumination can easily strain the reader’s pupillary muscles and degrade sight sooner.
Doesn't sound intuitive at all. How did they measure "better"? The natural environment is all reflective. Butterfly wings are reflective. Fruit colors are reflective. Human eyes evolved for the natural environment. Very very few natural things generate emmissive visible light. My eyes get exhausted reading on an LCD. I don't get that same feeling when reading on actual printed paper or on E Ink.
The cue is in the effort required to capture the message from a body of text. Reading has two broad stages–putting our eyes to feed the optical data and then our visual acuity in the brain (vision) to process that data--recognizing glyphs, putting together words, sentences etc.
If we concentrated on a butterfly or a fruit for hours on the end similarly, in a poorly illuminated environment, it is going to affect our eyes. The pupillary muscles have to remain contracted to let enough light in. A glow-worm on the other hand would feel more exciting and comfortable to watch in a dimly lit situation.
But that's only stage one. The stage two is where the magic happens. And it has a catch!
The morning/daytime spectrum from an LCD panel makes it easier for the eyes to capture the text because the illumination is great, but it also forces us operate attentively. By being attentive, our brain is pushed to operate at a higher energy level. It then uses more energy to process the load of incoming information and this whole deal exhausts us by the end of day.
Sometimes when we don't look at the evening shift spectrum of a sunset (reddish shift), our body clock does not trigger a restful mode. A fatigue sets in, if you will.
But this only means that it is time to take rest and not read anymore. Cue an IPS screen is still healthier for the eyes than a reflective e-ink one when it comes to long-haul reading.
[1] https://www.nobelprize.org/prizes/medicine/2017/press-releas...
Edit: Sorry wrote this one in a hurry. Have to go away from the computer now!
I find ink-on-paper to be difficult to read under direct sunlight as it is too dark. E-ink is virtually perfect contrast under such conditions.
With a "frontlight" layer, my Onyx BOOX is highly readable, though my preference is to have a bright light or reading light reflecting off of it, with the frontlight also enabled. In bright sunlight the additional light isn't necessary. In dim-lighting conditions, the light leakage through the inked-in portions is distracting.
One consequence is that "dark mode" formats are not well suited to e-ink, though they do remain generally readable. The fact that artefacts are more visible against a dark background may contribute to this.
I remember research and/or statements long ago (1980s) that brown ink on a slightly off-white paper has the highest readability, and know of several authors who had their books set like this. In general it's a good option.
For onscreen emissive displays, the variability between displays and ambient lighting conditions generally makes it a poor option, though for desktop use I'll often prefer a slight off-white background and very slightly muted text colour preferable. (Example of my typical CSS preferences: https://codepen.io/dredmorbius/full/KpMqqB)