Perfect Edition: A lightweight, responsive web e-book template

I deem that almost all of the value of pagination on most devices¹ is in static pagination: that you can refer to things by page numbers, that it helps your memory, things like that.

I am a Christian and read my Bible daily, and I know just where on the page a great many things that I might look for, which helps me to find them rapidly when I don’t remember the chapter and verse. In the not-too-distant past (say, 1800–2010), those people that cared about the Bible would mostly have a primary Bible that they used, and would get such advantages from; but increasingly people shift to using software Bibles, and Bible software is uniformly terrible for being one’s primary Bible. (Uniformly; there does not exist any software that is not terrible for this purpose.) I have thought long and hard about these problems, and have software in mind that, combined with the right hardware (which has to start with a high-resolution tablet with pen), could make a decent primary Bible. Operating primarily by static pagination (trying to pick the best features of the digital and paper worlds) will be an important part of this. It remains to be seen just how well spatial memory will work once the pages are not physically embodied; to my mind that’ll be the greatest hazard, and define whether I can switch to it myself.

To be sure, operating solely by static pagination in software is challenging: what do you do if you don’t have a known static device size? Shrink everything down tiny so that it’s not readable? Have done multiple columns on the page so that you can show just a column at a time? (That may be a possibility with Bibles which are commonly two columns per A5-or-not-much-larger page, but it’s not common outside Bibles.) Most commonly it’ll be better to give up on the pagination. So such static pagination is the sort of thing that Kindle can do to a large extent, but a general-purpose ebook that might be viewed on a phone, a laptop, &c. really can’t. Any reference materials like textbooks that are presented in PDF form for its static pagination will tend to cause at least some pain in matters of page sizing, and they’ll normally be accessed with vertical scrolling of pages rather than attempting to emulate a paper book too closely.

But other than when you have static pagination, on the aforementioned “most devices”, pagination is fairly strongly inferior to scrolling in its experience. For starters, you’re replacing a well-understood and consistently-implemented primitive with something that’s just… different. Different is normally bad. Different is even more normally badly implemented.

This project is going for pagination without static pagination. I think that’s a terrible mistake given how people interact with most works that might be framed in this thing (that is: mostly works of fiction that people will typically want to read from start to end). Its implementation is seriously dodgy: Shift+Space, Home, End, Page Up and Page Down don’t work. Scrolling with a wheel is just completely wrong and breaks the pagination model into smithereens.² Panning with touch breaks the pagination model into as many smithereens again. Swiping from outside the portrait page area doesn’t work at all.

To correct the final sentence on the first page of the demo:

Basically, nothing works properly.

Horizontal pagination like this is simply a poor fit for the web (and is very tricky to get right, or as close as you can to right, on general-purpose OSes).

But props on handling the no-JS case pretty well. :)

———

¹ “Most devices” means “devices that can handle scrolling well”, which means approximately any device with a high-speed display (such as an LCD or OLED display, and typically excluding e-ink displays) and some form of rapid and relatively precise means of scrolling (e.g. touchscreen panning, or a touchpad with scrolling, or to a very slightly lesser extent Space/Shift+Space/arrow navigation, so long as the user knows about them, and depressingly many don’t; ugh, the times I’ve seen people slowly move the mouse cursor across to the scroll bar with the ill-calibrated touch pad that they don’t realise offers two-finger scrolling, and click and drag the scrollbar thumb to scroll the page). For devices that don’t handle scrolling well, such as most e-paper reader devices, pagination has rather more obvious benefits.

² As an aside, it’s fundamentally impossible to implement scrolling fully correctly on top of a paginated source on the web, firstly because there’s no such thing as correct—users will want and prefer different things, all of them between hard and impossible—and secondly because hardware varies too much so that any attempts to make dual-axis scrolling work on the web will fail smoothness tests at the very least, and typically fail much more than that; and attempts to do things like scroll snapping to pages will irritate at the very least a substantial fraction of your users because it messes with their declared intent, and hardware varies enough in what it supports and reports in scrolling that it’s very impossible to do well for everyone. Outside the web platform you can do better on both these points, but general-purpose perfection is still pretty much unobtainable due to input hardware variation.

I would pay for an out of the box version of this with a bookmark feature. I am an author that can't code. Help

You might have a point in general, but the Bible is a poor example of the issue you highlight. The Bible has had the solution to your problem built-in for centuries already. Bible passages are identified by chapter and verse; no one refers to Biblical passages by page numbers. Bible software shouldn't bother with pages at all. It should instead allow reading to flow smoothly from one verse to the next, and only create hard breaks at chapter boundaries.

[EDIT:] Anyway it seems like conversion to PDF is what you want.

Haha we always reach for javascript first.

I agree with almost all of the content of Practical Typography. But “stop underlining links on the web” is the point I disagree the most violently with. Removing link underlines is user-hostile. There’s a large body of research to that effect: underlined blue text means a link, not-underlined text in a colour different from the surrounding text… might be a link? But many will miss it. “Are un­der­lined links dead? Maybe not quite. Dy­ing? For sure.” Nope. Not dying in the slightest. If anything they’ve been making a comeback as people come to their senses and realise that æsthetics aren’t the only thing to worry about. (You know what has really beautiful æsthetics? A pure white screen.)

Now in this particular case, I don’t feel the chapter headings should be underlined—because I don’t feel they should be links. As it stands they don’t even look like links, just like underlined headings. If you want to provide a link to this heading, do it otherwise: probably as a character outside the left margin of the heading or after the text of the heading, commonly using # or ¶ or U+1F517 LINK SYMBOL, potentially only visible on hover (not many people want to interact with those things, after all, so it’s fairly OK to conceal them).