In the days when Mobipocket and Microsoft Reader ruled the (somewhat small) roost, we didn't expect very much beyond what we saw in a text editor or word processor to appear on our screens when we read eBooks. Today things are different, we want engaging and interactive experiences, and the most obvious way to deliver these is with the open standards of the web.
However, not all devices will benefit from the cocktail of HTML, CSS and JavaScript of the modern eBook. A watch or a pair of glasses, for example, will be capable of little more than displaying the text in a limited range of fonts and sizes. This means that the majority of the code that contributes to the size of an eBook will be thrown out.
A speedier and more size efficient approach would be to not have all that code in there in the first place. In fact a great deal of HTML and CSS is devoted to compensating for inconsistencies in the way devices interpret HTML, CSS and JavaScript anyway.
It should also be observed that:
- The web as a whole uses HTML as an output, something that is generated by server-side languages interpreting data. It doesn't have individuals painstakingly marking up every single output, or even store data as HTML files.
- Twitter and Facebook are two of the web's biggest publishers and they don't store their publications in HTML, CSS and JavaScript, they store and release them via their APIs in JSON format, which are then interpreted by scripting languages.
- Native interpretation of ebook content could well accelerate display on wearable and mobile devices by not having the intermediary of what is essentially a web browser inside eReaders, as we generally have today.
- Native text layout is something that is undergoing a good deal of enhancement in iOS 7.
For me all these things beg the question over why eBooks are being locked into HTML, CSS and JavaScript by the EPUB standard, and even by those who are against the standard, when we should be looking to something more scalable that takes into account where the future of mobile devices is heading.
When eBooks are interpreted by a web browser, then by all means use HTML, CSS and JavaScript to display the data, but in other scenarios these might not be the most efficient solutions. Even the proposed e0 standard only attempts to address a very small part of the problem, as do proponents of books exclusively available inside the browser.
Unhooking our addiction to the web browser and its output technologies isn't about becoming more closed or maintaining control, it's about speeding up the ebook experience across all devices, and since two of the biggest guns on the Internet have shown their commitment to JSON, for this very purpose, it now seems the obvious storage medium for eBooks as well. While continuing down a path that doesn't see past XML and (X)HTML formats appears to be the wrong direction to keep heading in.
I acknowledge in the short term that there is a wider skills base and infrastructure in existence for managing (X)HTML, XML, CSS and JavaScript workflows, but it is also evident that the longer we keep going with these technologies, and the more they become entrenched, the harder it will become to break free and move forwards with nimbler options. Options that will greatly benefit books in the longer term.
Comments
Post a Comment