Why not regular Web-Browsers?

12 posts / 0 new
Last post


in the past five years, I have learned much about ePub. One of the biggest problems since I started was to find a good reader or reading software. I often hear that ePub is so bad. But its not the fault of ePub. It's mostly the fault of the ereader (software). There are so many out there for every system you may think about (a few hundred or even more).

But there is no reader really taking advantage of the ePub features. Not even close. Most don't know how to display basics. Readium is catastrophic in terms of user experience. iBooks has too much Apple specific features integrated to get things work. Most Android Readers can't display obfuscated fonts, CSS3 or even simple images. Kobo and custom CSS is no good idea. Tolino's software is pre-millenium. ADE has a huge bug problem. Windows,... not to talk about the results in the available readers. And these are already the good and popular ones.

What I don't understand. The major parts of ePub are completely based on common web standards and its good so. Only things like font obfuscation, toc/nav, ... are specific parts of ePub.

So my question to you (the IDPF) would be: Why don't you discuss with the Web-Browser Developers to integrate the ePub specific things into their browsers, so ePubs (refl. and fxl) can be natively read by Firefox, Chrome, Safari, IE, Opera, all kind of mobile devices integrated browsers, etc? Or why don't you develop a plugin which uses the popular browser rendering engines with its complete potential.

This would have so many advantages. There would be no need for developers to create API's for their readers them self. The choice of (bad) e-readers would significantly become reduced, where as the display and feature support quality would dramatically increase. In fact, I do not understand, why the known web standards need to be reinvented by newly developed reader software, where as there are already rendering engines, API's, frameworks available with good results. No need to even install an extra reader (unless the author/publisher wants to have its own bookshelf, ...). ePub3, CSS3 Support, Javascript, animations, Web Forms, Videos, Audio, ... would work the same way as websites. (Yeah, I design and develop also websites and know about how to deal with browser compatibility. But ePub is 100 times more worse for the moment.)

You can't continue this way. There is actually a complete chaos out there. The situation is: You manage the ePub standard, but no one (of your members) really respects it. Everyone does what he want. There is no common line in ePub creation, distribution and display quality (= reading experience). And that's very sad.

Thanks and kind regards,

IDPF and W3C are working at developing a format for EPUB that would work natively within browsers using the open web platform. See the EPUB+WEB white paper and Digital Publishing Interest Group, for example, plus each revision of the format generally seeks to harmonize EPUB with web technologies.


Hi Yves

I am well along the way to having a sophisticated demo for my version of epub-web which will only have 1 requirement - a button to download the offline file. Apart from that, as long as it works in a browser and all the media required is in the downloaded file, the format will work off-line.
Like the epub-web suggests, I am addressing 2 use-cases: 1) download a web page and 2) author sophisticated material for download.

I have built the prototype with WordPress, but other tools could work fine.

I am interested in encouraging the development of useful "hooks" so different components - CSS, JS, fonts, media, etc - can be easily added to a document - but these are not standards.

Regarding specs - 1) yes there needs to be a compressed file type that will open in browsers and 2) yes the browser needs to be able to use a manifest.

OTOH, my prototype stuffs everything into one file.

Finally I abandoned EPUB 3 a while back because it is ridiculous. Why have reader developers dictate what works and what doesn't. With browsers, while it is not a perfect world, it is far better.

I am in the process of reintroducing my site with working samples with more sophisticated and efficient prototype, but my original samples are on the web for downloading. http://5doc,org


My impression was, that many EPUB viewers already use libraries like WebKit/Blink or Mozilla/Gecko to get the content documents and CSS right.
Unfortunately several of them introduce unneccessarily problems by trying to simulate printed books, what is not a trivial task, at least for books with graphics inside and long words.
Therefore they typically fail, as readium does with its approach. For example the corresponding epubreader for Mozilla/Gecko viewers like firefox has a much better approach, it seems to use a simple frameset to set the navigation next to the content document, not much more than buttons to go the the next and the previous document and some interface for the metadata and to store books.
Therefore it is surely possible to provide a working epub-viewer right now, if one just does not try to simulate the behaviour for printed books, this introduces unnecessary trouble, these viewer do not manage anyway.

Hi Matt,

from what I have read, the ideas are good and pretty much on the same line as what I personally would like to see for ePub.

But to be honest. You are very far away from having even something in alpha state. What do Microsoft, Apple, Mozilla, Opera, Google, Kobo, Adobe, B&N tell about this. Are they even part of this project?

--- Off topic ---
You just need to look in the different forums for fixed layout ePub. Questions over Questions over Questions and claims on the display. Why? FXL ePub is nothing different than fixed websites, which most web-designers know to create since 20 years. Why can't such fxl ePubs be displayed (properly) on 97% of the readers? I really don't understand where the problem is.

More worse is the situation what O.H. writes here. He/She is completely right. Most readers have access to Webkit, Gecko, etc. But they are blocking parts of the CSS, JS, ... or they are ignoring parts of ePub, they are overriding features and so on.

epubtest.org is a first good step in the right direction. Why don't you (the IDPF) introduce a certification for your members or other developers and publishers which require to bid a certain quality, respecting by example 95% of the test suite criteria's to become qualified.

Passed all tests = certified IDPF Reader or Certified ePub Creator
Passed less than x tests = no certification

ISO, TUV, CE, ... do this since years and it works.

The web itself is still a long way from providing for really good online/offline reading experiences, or pagination, so it's a longer-term project, of course. I was just pointing out that the need for the industries to reconverge is understood by both the publishing and web sides, and there is a joint effort underway.

W3C interest groups also can't publish standards, so at this stage the work is more focused on what needs to be in place and providing a concerted push within the relevant W3C groups to ensure that publishing needs are being addressed. I think when they recharter the group they may start to look at practical implementations, but much of what is needed is still only early draft theory.

And bear in mind that IDPF is a consortium of member companies, as is W3C, and just as "W3C" can't pressure the browser vendors to implement their standards properly -- where's mathml support? -- IDPF can only provide the standards that everyone agrees on for publishing. Many of the companies you note are members of both and are involved in both efforts if they're involved in the publishing sphere (i.e., the pure browser-only makers not so much).

The "forum" part of the name isn't just branding, either, as the standards work does provide the opportunity for the content creators to get involved with development, and to express dissatisfaction with the current state of support, so it's not just reading system developers working in a vacuum.

Certifying reading systems, for example, has popped up as recently as last February at the Phoenix EDUPUB meetings. It's not as easy to get agreement on how it should work as you might think, though, as not everyone needs or wants all parts of the spec. An EPUB reader doesn't technically even need a viewport, as the format is designed to enable consumption by blind readers. I recall the discussion getting bogged down in how many different types of reading system/content would there have to be and would it make buying them and purchasing content for them even more complicated for consumers. Doesn't mean it won't ever happen, but doing something you don't get right isn't helpful, either.

Similarly, you can hate the paginated look and feel of ebooks, but it's driven the ebook market. You can't tell readers how they're supposed to read, or vendors and publishers to stop creating content that way when it sells for them. There are many readers who still feel eink is the pinnacle of ereading, after all.

Anyway, long story short, as with most things in life there's always a trade-off between what you'd like to do and what you have the time and resources to do, and what your customers are demanding of you. That holds both on the standards side and on the implementation side.

As I'm not an IDPF spokesman or anything, I'll leave my opinions at that.

About fixed layout - well as table layout somehow outdated for webpages and surrely not a good approach for EPUB books as well. It never really worked with (X)HTML+CSS, typically a user just has to select a minimal font size or an own preferred font size and such styling is broken. If a user-agent/viewer blocks this option, content easily becomes inaccessible for parts of the audience.
Fixed, but scalable layout is possible with SVG, but boxes with automatic line breaks for text are available only in SVG tiny 1.2, not available for EPUB.
Because SVG fonts are not implemented in many viewers, it is hardly to predict for authors,
how to break text into lines manually or with a script as well.
If one really needs a fixed layout for a book to be printed for example, still LaTex->Postscript/PDF is a good approach, this worked already before the turn of the millennium and still works now. But this is no good approach for longer text displayed on a screen.

About faulty viewers:
There seems to be currently only one way for improvement of at least payed devices with faulty viewers: Test EPUB features, document it and give the device back as damaged, if it fails to hold, what the developers promised. If enough people do this, soon devices with mad or bad viewers will vanish and others will get a better chance to be noticed by the audience.

Does anyone here remember the Ibis eReader from Threepress? Threepress was bought out by O'Reilly and retired. While it existed, it was a great example of an HTML 5 eReader. It even used local storage for offline reading. I often wonder what it would be like had development continued through his day.

I should also ask: Why has Radium.js not resulted in at least a few prototype web-based eReader systems capable of rendering the more popular aspects of EPUB 3?

An EPUB3 Reader arguably has nothing to do with a Web Browser, so maybe the more fruitful question would be, why Web Browsers?


"Finally I abandoned EPUB 3 a while back because it is ridiculous. Why have reader developers dictate what works and what doesn't. With browsers, while it is not a perfect world, it is far better."

EPUB 3 is actually the best thing since the Kindle for eReader enthusiasts. Developers do not dictate what works or doesn't work; the EPUB 3 spec dictates what should work and it is up to Reading Systems developers to get it right. The fact that it hasn't happened yet is testament to the fact that EPUB 3 is a comprehensive and hence promising format for making long-lasting standardised format ebooks. There is not much difference in the challenges faced when writing a Browser Engine vs. EPUB Engine, it's just that the EPUB eReader is a new concept and developers haven't had as much time to work on it.


1. The problem with the approach of just using a browser is that it limits you to the browser that support the features you depend on, or you have to have a backup polyfill approach.  Both approaches will work some to most of the time, but that is generally not a successful strategy.  This is a subject that is part of the current EPUB 3.1 WG discussions, but the problem is not simple.

2. Readium supports both the CloudReader (see http://development.readium.divshot.io/ ) and the Readium Chrome Extension (see https://chrome.google.com/webstore/detail/readium/fepbnnnkkadjhjahcafoag...).

Secondary menu