Concept


Let us begin with a simple definition. What is a book?

Book is a collection of nicely formatted pages.

Where the collection is essentially a stack of pages and not a list.

Basic HTML:

There isn’t a <page> tag in HTML standard so we’ll consider iframe as the nearest equivalent single unit of a page. Since book is a collection of pages, the following HTML describes the basic structure of a book well:

<div id = "book">
    <iframe srcdoc="…"> render of page-1 subresource </iframe>
    <iframe srcdoc="…"> render of page-2 subresource </iframe>
    <iframe srcdoc="…"> render of page-3 subresource </iframe>
    …
    …
    <iframe srcdoc="…"> iframe of Page-2N here…</iframe>
</div>

Note, we don’t use <ul><li></li>… </ul> as a corollary because book isn’t a list.

Since <page> is an iframe it has the same HTML structure as any other webpage on the Internet—as in, it follows from the same HTML tenet that makes the web. Except in this case the existence of the <page> is tied to the <book> container instead of a website. Also, since there isn’t a <book> tag in HTML standard either (like there is a video tag for videos say), we use a div#book to encapsulate pages on an ordered stack.

The order is important here, in that it represents the reading direction and the flow of a story that has been cut-up and paginated this way for deeper accessibility.

The HTML structure described above is quite close to a real book on production.

Observe that there are 2N number of pages (or iframes) inside a book and this could not be an odd number. Here’s why:



A Superbook utilizes what is called a bifolium design, which introduces the concept of a front and a backface of a leaf (similar to backface-visibility of elements in CSS). Since a leaf has two faces (pages), a book with 15 (N) leafs will have 30 (2N) pages in it.





Interestingly, as seen from above, handling multiple pages on a book is a lot like handling multiple webpages on a website. Only the behavior and arrangement in stack is that of a book. Oftentimes developers think that page turning and rigid stacking is like mimicking a physical book, and, therefore superfluous to the nature of web, but that is not an accurate view. Not anymore than mimicking a physical scroll that we’re so used to.

Superbook

The Superbook container is made up of HTML structure as shown above with each <page> a virgin iframe that is rendered independently either dual or single view depending on landscape or portrait mode. Each <page> contains a sourcedoc i.e. content that is rendered in real-time and is sandboxed from the rest of the book like a typical single page app (SPA). The SPA itself is offline-first using a serviceworker to make way for offline reading.

Note the parent window i.e. the root_url on which all the pages (iframes) are loaded doesn’t contain any content. The root_url is also sometimes referred to as the spine_url and it holds the entire book (longform) in a paginated format that is accessible via page numbers appended to the end of the url like so:

https://bubblin.io/<— your book url —>/page_no

Counting pages

Page numbering on Superbooks is kept simple. The pages are counted from the cover page up until the very end i.e. back of the book. Page numbers are displayed on URL bar at the end of the book_url (or root_url or the spine_url). Here’s how it works:





It is highly recommended to turn page numbering on on textbooks. Enabling has_page_numbers: on helps the reader to not only see where they are on the book but it is also the only way for this information to be available on mobile phones (the url bar in portrait mode is too short). Read more about accessibility guidelines for Superbooks.