I deem that almost all of the value of pagination on most devices¹ is in <i>static</i> pagination: that you can refer to things by page numbers, that it helps your memory, things like that.<p>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 <i>terrible</i> 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 <i>primarily</i> 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.<p>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 <i>column</i> 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, <i>&c.</i> 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.<p>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… <i>different</i>. Different is normally bad. Different is even more normally badly implemented.<p>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.<p>To correct the final sentence on the first page of the demo:<p>Basically, nothing works properly.<p>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).<p>But props on handling the no-JS case pretty well. :)<p>———<p>¹ “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 <i>don’t</i> handle scrolling well, such as most e-paper reader devices, pagination has rather more obvious benefits.<p>² 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 <i>will</i> 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.