• Print

Are we over-thinking EPUB?

The future of the book is inherently linked to the browser

One common misnomer I have come across is that EPUB3 is ‘a technology’ – something in and of itself. I believe this category mistake is largely a result of the the IDPF’s (the organisation that maintains EPUB3) success in promoting EPUB as a ‘standalone’ technology to the publishing world.

While all content is trending towards CSS and JavaScript, the core technologies of the browser, it seems a little weird to position EPUB as being a collection of things that do something different from what browsers do. The nuance might not be clear so here goes…

EPUB is essentially a collection of standards wrapped up inside a zip file with a few extra bits that ‘bind’ the content together. The extra bits give metadata and information needed for books including a table of contents, etc. Most of the standards wrapped up by this zip file are standards made for, or predominantly made for, browsers. The line is blurry of course. Is HTML 5 a browser technology? No, it is a standard that could be implemented by anything. But lets face it…browsers came into existence to render HTML and kind of became the name for that sort of technology.

Add into the mix CSS, used to style webpages displayed in browsers, and JavaScript, used to program webpages through browsers – browsers became software capable of all kinds of things. At the same time some things became capable of working with these technologies. It is possible, for example, to manipulate HTML using tools that are not browsers. You can, for example, use programming languages for creating and interpreting HTML for all sorts of reasons (like file conversion) without the content ever seeing a browser in its lifetime.

However, when does a tool share so much functionality with a browser that you just call it a browser? When does a duck become a duck?

I believe that any technology that does all that EPUB requires it to do is a browser.

EPUB requires HTML, CSS, bitmap support, MathML support, vector graphic support, JavaScript, etc., etc., etc.

All of this stuff is just common browser stuff. If you need to read an EPUB and display it, the technology you are using is a browser. Its not an ‘ereader software’, or ‘ereader’, its a browser and let’s call it that.

If it has feathers and quacks, it’s a duck.

Why is this mild semantic re-orientation important? Well it’s important because the very foundation of the discussion about what EPUB should be is based on the assumption that EPUB is something of itself. That starts an entirely different discussion than just simply stating that browsers are the things that read EPUBs.

Case in point is an interesting statement from Bill McCoy from the IDPF (I have great respect for both Bill and the IDPF) that the addition of JavaScript to EPUB3 was a controversial decision (see comments here). Extremely interesting. If EPUB was discussed as being something to feed browsers content you would imagine that JavaScript would be the first on the list to be included. Why not? JavaScript is already there on a platter in browsers and in a very mature state – you would be foolish to ignore it and foolish not to include it as a supported content type.

I don’t mean to hold up this apparent controversy as anything other than an indicator of an interesting problem. We are pretending we are dealing with something special – EPUB – and weirdly this is limiting our understanding of what we are actually working with – browsers.

The future of the book is inherently linked to the browser. Discussion of EPUB as a technology somehow ‘separate’ from browsers is not helping us see that very rich and quite unbelievable future, one that is entirely different to what is in front of us now. If we see EPUB as something other than a subset browser functionality we are not seeing the present or the future clearly.

I’m not sure what is holding us back from this way of seeing things. It could be that we somehow consider the browser too mundane to be the future of the book. It could be that the browser is too scary as it gestures strongly in the direction of ‘the web’ and content out ‘in the wild’. It could be that all of this triggers challenges we don’t want to consider – challenges to current business models, the status value of the book, professional pride, roles, and infrastructure. Whatever it is, I am sure it’s there; legacy ideas that prevent us from understanding what is actually going on, from understanding that an EPUB is nothing special.

We could perhaps clarify this by calling EPUB a standard for ‘portable websites’ and stop talking about books altogether. It would be interesting to spend a lunch hour thinking about that simple statement and how it would affect what you do.

tags: , , , , , , ,

Comments: 34

  1. I don’t see much evidence that EPUB is being promoted as a “technology” but an open standard ebook format. People who buy ebooks should request them in the EPUB format so as to maximize the number of devices it can be read on and to avoid being locked into proprietary technologies.

    As far as the browser question, I think of an EPUB reading system (and any other ebook reader) to be a software wrapper around an HTML engine. When I say “HTML engine”, I mean it renders HTML, JavaScript, and a host of associated rendering languages. The wrapper supplies the user interface outside of the page content and includes ways to set viewing options, paging buttons, etc. A web browser is also a software wrapper around an HTML engine like an ebook reader but it implements a different user interface.

    The controversy over whether JavaScript should be in EPUB3 confuses a lot of people. JavaScript is typically used in the implementation of an ebook reading system since it is the most appropriate language in which to implement the reading system’s user interface and comes for free as part of the HTML engine it is built on.

    The controversy is about JavaScript in the EPUB file itself. An ebook reader presents a much more restricted interface than a web browser. Web pages can use JavaScript and other technologies to implement games, alternate user interfaces, and so on. An ebook reader’s interface must present a paginated content experience that is analogous to a printed book. While it can evolve to offer interaction that is much more varied than that of a printed book, it can’t really go as far as a web browser and still be called an ebook reader.

    If arbitrary JavaScript is allowed in ebook content, it is bound to interact with the ebook reader’s user interface in unforeseen ways. It might even contain some kind of malware. There is an expectation on the part of the user of an ebook that it is safer than browsing the web. This promise might be violated by ebooks with arbitrary JavaScript and other web page technologies. If we allowed this I am sure we’d be talking about ebook viruses in short order — at least ebook bugs!

    • Hi Paul, 

      Thanks for great comments.

      Given that many ebook reading devices use webkit as the base for the reading software I am not sure I see the difference between ‘browser’ and ‘HTML engine’. I don’t think there is a difference. 

      It is a critical point because building support for these things is difficult. If multiple vendors make multiple implementations we get nowhere along a lot of disparate paths very fast. If the vendors instead adopt an existing software like webkit as the base for the reading software then everyone gets pushed along the same road a lot faster.

      I think we should stop trying to make arbitrary differences beween these things. EPUBS are read by browsers. Thinking about it in any other way stunts progress.


      • There is a big difference between “browser” and “HTML engine”. A browser is an HTML engine with a user interface on top of it. All browsers are structured this way. IE has an internal HTML engine called MSHTML (it has other names too) and many Windows apps make use of it to display formatted content. For example, the Windows Help app is an alternate wrapper around MSHTML. WebKit is the HTML engine that is the guts of the Safari and Chrome browsers, among other things. Mac apps can also make use of this HTML engine to display formatted content. An ebook reader is just another wrapper around an HTML engine.

        While there might be some advantages if every ebook reading system used WebKit as its HTML engine, it is not really as important as you might think. The W3C’s HTML5 family of standards is working to ensure that all HTML engines do the same thing. While WebKit is likely to be a popular choice of HTML engine for ebook reading systems, it really won’t matter from a standards point of view or from a user point of view. An EPUB book’s HTML, SVG, etc. will be processed by some HTML engine within an ebook reading system but it doesn’t really matter which one because they all implement the same standards.

        No offense but I believe these “arbitrary differences” you refer to are largely gone. At least that’s the plan. As with all technology, our vision is imperfect and your mileage may vary.

        • Some semantic slippage is going on I believe. ‘html engine’ with ‘a front end’, ‘browser’, and ‘ebook wrapper’ aren’t all different things. They are the same thing. Lets just stick with one name  –  browser. It is the correct useage, a much more meaningful way to talk about whats going on, and doesn’t obscure what we are dealing with.

          • It is not constructive to just say that I’m wrong without any kind of explanation. I stand by what I said. Those terms are not the same thing just because you don’t understand them.

          • ok. Sure, sorry. I didn’t mean you to feel I was chopping you down, your points were good. I was hoping to continue the conversation. My sincerest apologies.

      •  If you know what webkit is, then you already know the difference between “browser” and “HTML engine”, because webkit is not a browser, but it is an HTML engine. An HTML rendering engine can be used in lots of things that are not “browsers”. For instance, an e-reader, or the Windows 8 “Metro” API, or an email client. Your original article makes a decent point, but Paul’s comments add something worthwhile to that point, which is to say, a little more precision in the definition of “browser”. EPUB then becomes best defined maybe as a sort of standard collection of the HTML toolkit and techniques for using it in a manner that can reasonably be expected to be completely usable by a particular one of those types of software built on an HTML engine (an e-reader). In a way, I suppose, the relationship between EPUB and HTML is like that between XHTML and XML.

        • yep i know the difference but its not an interesting conversation to have I believe.  That differentiation is more useful for technical discussions. I dont find it so interesting here and find it obscures a lot of what we need to understand about what it is we are dealing with.

          • Maybe, but it could be the other way around- calling everything a “browser” also can obscure what we need to understand. There are commonalities to all interfaces built on top of the basic elements {internal combustion engine, wheels}, but you can’t suggest that we’re obscuring things by discussing whether there is such a distinct thing as a “locomotive” just because you want to say “they’re all cars in the end”. They have an underlying basic structure which is founded on the same technology, but based on their purpose, they may take or leave certain elements of what makes up a car– a train has no need for a steering apparatus, for instance.

          • I think that misses the point. but anyways, maybe best to leave this conversation here and move on to new ground 🙂

    • “If arbitrary JavaScript is allowed in ebook content, it is bound to interact with the ebook reader’s user interface in unforeseen ways. It might even contain some kind of malware.”

      Agreed. The sheer volume of books that are published every year (it’s in the millions, I think) means that the negatives to something like JavaScript (security and QA concerns) far outweigh the positives. If something has so much interactivity and multimedia that it requires JavaScript or anything else unsupported by the current standard, then, frankly, it’s probably a website and not a book.

  2. Even with basic narrative industry EPUBs (see John Cavnar-Johnson’s excellent post breaking down the various industries contained under the banner of publishing here: http://www.digitalbookworld.com/2013/there-is-no-publishing-industry/ ) – I don’t think that you can completely classify EPUB as a subset of HTML/CSS/etc. or just another *web* standard. 

    EPUB supports linear ordering of chapters and page breaks because these mechanisms are extraordinarily important to pacing and drama in narrative texts, and these features run counter to web browser design, and to the very nature of the web. *So* counter to it, in fact, that you can see it in the structure of the EPUB file: it’s pretty awkward to manually make a list of the chapter order and have all the chapters in separate files, considering how intuitive this sort of thing is in a print book.

    • hi Stephanie. 
      Nice points but I if you don’t mind I would like to disagree with them.Its pretty easy to order html into a table of contents and pretty easy to paginate html content. You may wish to look at the html region code that has recently been implemented in webkit. As an example have a look at this post I made earlier:http://toc.oreilly.com/2012/10/bookjs-turns-your-browser-into-a-print-typesetting-engine.htmlThats all html with standard CSS and JS. adam

      • Hi Adam,

        Thanks for the link. I am pretty interested in ebook-first book development, so BookJS looks great to me. Are you on GitHub? Will follow you if so.

        An in-browser pagination tool that prints to PDF, however, if anything just makes your greater argument (that in the future we will not have book-reading apps separate to web browsers*) murkier.

        I did think of a prominent example that supports this point, as well as my larger point (that some incontrovertible aspects of narrative text run counter to the nature of most web browsing): the new tablet version of Google News.

        Google News, on Safari on iPad at least, supports page breaks (scroll to the end of a section and it stops) as well as linear order (sections are dynamically ordered by its engine via a predetermined news hierarchy: Features, Local, Business, etc.)

        I can see getting quite used to reading books in this way: vertical scrolling through a chapter and then horizontal scrolling to the next chapter (as long as there is smart snapping on the vertical also). 

        I can’t speak first hand about IDPF deliberations, but I think that some of the preciousness about EPUB might stem from (mostly legitimate) QA concerns at Apple, Google, B&N and others who use the standard. At least one of these companies reviews uploaded ebooks closely before publishing them in its store, just like any other third-party developer software, and this process is faster when EPUB is simpler. I highly recommend the JCJ post that I linked to before – http://www.digitalbookworld.com/2013/there-is-no-publishing-industry/ – I think it explains a lot of the kind of confusion you come across frequently when dealing with ebooks issues.


        *Sorry for extrapolating. Let me know if this is wrong, and I’ll edit this.

        • hi Stephanie,

          My point about BookJS is just to show that all the things that books need, no matter which way you turn – print or electronic. Are now managed by browsers. 

          As for scrolling etc. I think reading on the mobile highlights the issue very well. We are needing to paginate mobile content for smaller screens all the time. Paginating content for mobile is more and more being handled by in the device browser by default these days. Just like books in ‘ereaders’ (which, as I mentioned, are the same thing). Pagination is just common browser business these days. 

          If you would like to follow dev on github I lead the dev of bookype:

          and bookjs 

          and a few other things. I will be pointing to some of the projects I’m involved with next week in the context of another post (about forking).

          Thanks for the link. Will follow it up.


          • I tried downloading Booktype’s EPUB manual on Flossmanuals to my iPad, and iBooks says that it cannot open it.

            When looking at book publishing software the first thing I do is try to look at the sample books created with them. PressBooks’ book (purchased from Amazon) did not have adjustable font type. Booktype’s book did not even open.

            Very strange.

            I hate to be harsh towards open source software devs, but this looks pretty bad and results in authors getting frustrated and outsourcing ebook conversion to vendors. I think the future is authors making their own high-quality ebooks, but I have yet to see a WYSIWIG editor that doesn’t result in a buggy product. 

            Maybe because the future is to train authors in the basic HTML needed to create a good ebook base, and not WYSIWIG?  I am not sure.

          • hi Stephanie. Thanks for the conversation and really great you looked at FLOSS Manuals (FM). Just FYI, the code used on FM is actually a predecessor of Booktype and the code there is about 2 years old. Since 1 year we have had 1 full time dev on Booktype and since 3 months now we have had a team of 3 full time developers on Booktype and the improvements on the code base are vast. Booki was the predecessor and the code is mainly developed through volunteer hours. I quite simply havent had the time to upgrade the FM install from  Booki to the latest Booktype because the work managing Booktype itself has increasingly swallowed me up. Still, i hope to get to it at at FM meeting in March in France.

            As for WYSIWYG, I totally agree with you. You may wish to look at this post which is related to the topic:

            Also, by the way, Press Books is not open source. They are promising to make it so but I havent yet seen a link to the repo etc. 

            As for open source in general. I think you have to be harsh with them. Its the only way to get them to beat everyone else. But you also have to play ball with them. Its part of the same deal 😉

            Thanks heaps for your really interesting part in this conversation. Hope to see you at ToC if you are going.


          • Okay, I see the problem is the EPUB generator on Floss Manuals. Sorry for the confusion. 

            I am very much enjoying the conversation too, and take full responsibility for jumping in and commenting without knowing too much about a lot of the stuff being discussed on this blog.Do you have any free books created through Booktype up on iBookstore or your website?  As I mentioned in my earlier comment, I like to see the finished product and recommend linking to such samples in the Booktype ReadMe.

            That way I can revise my above assessment too.

          • hi

            There have been heaps of epubs for ipad made with booktype. I think some on the store but I actually dont know. I usually dont follow it that far. Here is a pic of some books we created in dec of last year:

            ipad, kindle, android, paper


  3. Matthieu Ricaud-Dussarget


    I agree with Paul : HTML engine is the “deep” technology to render an HTML page with all implementation of markup rendering, javasript, SVG, SMILE, CSS… When adding an user interface on top of it, let’s call this whole thing a “browser”.

    User interface is not only about button on top of the page, it’s also the way the user iteracts with the content : right click, increase font-size or zooming the whole page, and last but not least scrolling the page !

    “Epub browsers” has a really special difference with web browser in the interaction. The most important difference is about scrolling that does not exist, cause the user has to “turn the page” to read the following content. And this is really not easy to implement : the epub browser has to calculate the page height to decide how much content has to be displayed in this page. If an image come at the end of a page, is there place enough to display it or should it be place at the beginning of the next page ? This is dynamic pagination.
    What about orphans, “end page” notes,  or full page images, how to avoid blank pages when using page-break css instruction …

    Pagination is actually something hard to deal with and this is maybe the new point in ePub.

    The other point in an “epub browser” is that you just have to turn the page to go to another HTML file, it is transparent to the user that this content comes from one file and this from another. The HTML file is not the unit anymore : the page is the new unit.

    You should be able to print a whole ePub file, printing a web whole website is something else… “Playorder” is something specific to epub. 

    But Epub3 introduces also special epub attributes on XHTML markup, this is no more html namespace but an specific epub one. it can but used for notes for example, the epub browser is then free to implement his own note system (popup ? or something else). This special epub vocabulary inside XHTML has maybe to be consider in the term “Epub technology” ?

    But well the core technology is the same, more restricted maybe (no ajax, no interaction with servers or any external content..).

    Let’s add “I think”, “According to me …” at the beginning of all the sentences of this post 😉 

    Hope this helps


    PS : I only deal with “normal” epub here, not fixed layout epub or “no-linear” parts of a epub which are closer to website.

    • hi

      Thanks Matthieu for your comments.
      I think you are diving down into some technical detail which is a little arbitrary and also in some cases incorrect. EPUB browser pages are not one html page, for example.

      But I want to zoom up a level. Everything a epub needs is stuff that browsers do. Making a difference between browser and ereader based on something like page flips or spine is just arbitary and incorrect. Phone browsers, for example, deal with page flips. Website navigation does the same thing as a spine. You would argue (and I would disagree) that there are very small differences in how this is technically executed ‘for a book’ and for ‘a website’. Not only do I disagree with this I also think that is an uninteresting conversation.

      EPUBs and webpages are the same. The thing that renders them needs to do the same in both situations and the actual background engine is often literally the same. If we can recognise this the conversation becomes much more interesting. Otherwise I firmly believe we are kidding ourselves and preventing ourselves from having a real conversation about what it is we are actually dealing with and how it effects our future.

      The responses to this post are really great but they also affirm this point.


  4. If my experiences with trying to print web page content to a printer is anything to go by, there are many reasons why we cannot treat web content and e-book content the same. The underlying technology may be the same, but this debate is more about what is practical to include into an e-book file that an e-book reader can reasonably be expected to render in paginated format.
    Let’s not also forget that many e-book readers push themselves as exceptionally low power (long battery life) devices. The introduction of JavaScript into that mix is going to impact the kinds of devices that can successfully render those epub files.

    • hi

      Im not sure I understand your first point. I agree with battery life in general. I try and read with my phone but my phone battery is terribly bad and I dont know anyone that would say they have a phone which has a satisfying battery life. So phones as readers are ok but suffer greatly because of this. Im not sure how much JS will effect battery on ‘reader’ devices, i guess thats something we can wait and find out. One thing for sure though, it wont stop people from making great books which implement JS in amazing new ways. Hardware may have to catch up, lets wait and see, but if it does need to catch up I dont believe the lag will be very long going by current R&D on mobile devices since the market exploded a few years ago.


      •  My first point was that to equate web content to e-book content is to miss the point that a lot of content found on the web (for good or bad) is insanely difficult to render into pages. A lot of the techniques used on Web 2.0 sites are anathema to paginated content which explains my problem with trying to print web pages out. Many others have the same issues. The print issue is merely a symptom of the problem, not the problem itself.
        e-book content is necessarily a subset of what an Internet browser generally has to deal with which leads onto my second point to do with our expectation of e-book readers in terms of their computation capacity. e-book readers have an expectation of long battery life not because they have great batteries, but because they are very efficient. e-ink requires power only to change the display and is quiescent at other times. JavaScript is often used for animation and other effects. The expectation of an e-book reader is that the page is composed, then it goes to sleep. More “active” e-book content will affect this expectation. As long as JavaScript is just used to aid the static composition of a page, well fair enough. I suspect that it won’t end there though when the race to “differentiation” between publishers pushes that envelope inevitably to something with more “sparkle” and we will see the battery lifetime of these devices drop through the floor.
        Oh, and has anyone mentioned JavaScript viruses yet? Jesus, let’s not go there, please.

  5. I much prefer the PDF format.

  6. I would rather say we’re under-thinking epub — but fully agree with you.

    I used to be worried about things like javascript in epub files. But most technologies will simply not start “native” or even organized. Take MathML for example which for over a decade had not seen much progress on the browser side until MathJax came and just solved the problem. And yet, the situation for epub3 is still screwed up since reading software just isn’t honest about how broken its support is (I’m looking at you iOS5…). So people started putting MathJax inside their files. Is it “wrong”? Yes, but can anyone blame people to get the same quality they get on a webpage?

    More importantly, MathML is only a first step — mathematics will be laying the ground work for all native scientific content. Could ChemML make it into HTML? Could a standard for statistical data emerge (which does not deserve image rendering either with its lack of copy&paste, search and interoperability)? None of these will be native immediately.

    Maybe Stephanie’s comment is right and the overhead is too big. But from what I hear from publishers, they are already there, in a reality where ebooks are as complex as any other web app (though different). If we want to actually move beyond “print book replication”, then ebook reading software must be very transparent at what it does and above all needs to get out of the way of the content.

  7. Apply this to ePub2,  a packaged version of
    HTML, but for whatever reason I will skim through a web page but get lost in
    stories and text within an ePub, the consumption of the file is different,
    feels different and presents different possibilities for layout. Just as with online
    magazines, why would we need to package that content into a magazine rather
    than just have it on the web. Is it the centuries of human conditioning that
    allows us to access a different mindset when reading a simplified layout? Yet still turning pages even though they are digital. Another strange nuance of human
    behaviour perhaps? I’m glad we get a more complex toolset to layout books digitaly and bring another deeper mindset to layout and content. Interesting article, thanks.

  8. Hi Adam,

    Sorry for my lately response, too much busy with ePub conversion actually 😉

    Just because I’m a bit susceptible… you said :

    “I think you are diving down into some technical detail which is a little arbitrary and also in some cases incorrect. EPUB browser pages are not one html page, for example.”

    I didn’t said that, I meant “a new html file will always come in a new page inside an epub”, not every new page is an HTML file of course ! But maybe it was not clear in my sentence (I wanted to make it short enough).

    We are all arbitrary in a debate, for luck. I actually was dealing with pages because at first I was seing an epub as a website, my experience leads me to think that the key difference is the page which is the proper of a Book. I did’nt mean to lead the debate to a technical details, but just this main question “What is a book ?”. We see books as something printed, even Word document has pages for this goal and or just because it’s usefull to have “units”.

    But well I globaly agree with your point of view : ePub is not a own technology but a mixe of standard web technology that one can find on the client side of a website that we call a browser.

    At the beginning when javascript was not alowed in ePub, maybe it was not that clear ? I didn’t follow all discussion about that, but I guess the IDPF thought an epub has to “look like” a book, printed one, and not like a website. That’s maybe why they did not allow javascript in the early epub time. XHTML was also restricted : any forms element like button, textarea or inputs are not allowed in ePub 2. Today HTML5 within ePub 3 let’s do quite everything you can do in a browser. I think it’s a good thing cause it make to format more open to a new way of seeing books, more creative actually and maybe dangerous in an other way ?

    For example, scolar printed books use paper interaction for exercices (“see the answer at this page” or “reed the book upside down to read it”, etc.). Why should I reproduce this paper interaction inside a numeric format ? Because I’m not allowed to use forms and javascript whereas it’s perfectly adapted ? this would be a non sens I think. Books are differents and javascript can helps to deal with this.

    What about ajax ? Would it be interressant for an epub dealing with economy to update data tables for example ? But what about the textual interpretation of the data, has it to be update too ? That would mean the content of the book is not definitive and could change at any (?) time. In this case we would be very near to website… Good ? not good ? hard to say. Depends how it is made I guess, maybe it might be usefull in some cases, on a few pages, as long as the user warned about it.

    What I actually miss in ePub technology is the concept of “library”. If the user has another book in his reader, I would find usefull to be able to make a link to it (if the subject is the same or near). With the help of semantic technology, maybe we would someday achieve this ?

    Hope the zoom in not out of the topic.



  9. I think epub should just be thought as a medium for a product and item… a “book”, and there will also be a need for “apps” in the same way.. and everything done using regular web technology which is amazing. But it need some kind of packaging so it will be managable and when aprropriate sellable in shops and the like…

  10. Yeah, you points are really good. And I think there is a big difference between “browser” and “HTML engine”. A browser is an HTML engine with a user interface on top of it. Here, ePub or HTML also can easy read. Here i recommended tutorial on http://www.ipubsoft.com/html-to-epub-converter/webpage-to-epub.html how to read webpage to ePub eBook for iPad, Nook, Android, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *