The next day, I spoke to a manager from a document conversion and app development company on the BEA show floor. He said that his company recommends to publishers that they use EPUB 3 as the basis for creating eBooks. I asked, "But what about Amazon? They don't use EPUB 3." The representative said that Kindle Format 8 is "very close" to EPUB 3, and that Amazon might adopt EPUB 3 in the future. In any event, he said, it's fairly easy for his firm to convert EPUB 3 to KF8.
The era of "Browser Wars"
I came back from New York with a bad case of déjà vu. Anyone who was involved with the Internet from 1995 on remembers "Browser Wars," the battle between Netscape and Microsoft to dominate the web browser market. The engineering team that developed Mosaic, the first graphical web browser, at the University of Illinois, moved to Silicon Valley and wrote a new browser, code-named Mozilla, that became the Netscape browser. Netscape quickly became the most popular Internet software ever released to that date. Then, Microsoft licensed the original Mosaic code from the University of Illinois and released its own browser, called Internet Explorer.Early on, Netscape introduced new tags and functionality to its browser at a fast clip. Some of these tags, such as frames, gave web designers more options for creating web page layouts, but the tags were implemented without being adopted by the World Wide Web Consortium (W3C,) the international standards-setting body for the Web. Microsoft adopted some of Netscape's tags and added many of its own. However, even when it adopted a Netscape tag, it would often adopt a different set of attributes (the settings that tell the tag what to do.) There were also variations in how browsers rendered tags: The exact same web page, using the same HTML tags and attributes, in two browsers that supported all the tags and attributes used in the page, could look different in the two browsers. For example, in one browser, the page might be displayed with a background color that bled all the way to the edges of the window, while in another browser, the same page might be displayed with a white border around the edges.
It wasn't only HTML that got "innovated" to pieces. The same scripting language got two different names--JavaScript at Netscape (where Brendan Eich invented it), and JScript at Microsoft. As with HTML, the two companies' implementations were different in subtle (and sometimes not so subtle) ways. This was the era of "Looks best in (Browser X)" and "We prefer (Browser X)". In some cases, web pages wouldn't even open in some browsers, and the user would be told to use or install a different browser.
Browser developers encouraged these differences in order to lock customers in, but they were a nightmare for website designers, who had to design different versions of their sites for different browsers, and even for different versions of the same browsers. Pressure from designers and software developers on browser vendors and standards organizations reduced, but to this day still hasn't completely eliminated, the requirement to do things in different ways for different browsers. The W3C took charge of defining new versions of HTML and pushed vendors to stop implementing their own new tags until they'd been reviewed and accepted by the W3C. The W3C also adopted Cascading Style Sheets (CSS,) which over the years have made it easier to tightly define the layout of web pages that work across browsers. Ecma International (formerly the European Computer Manufacturers Association) took over standardization of JavaScript, and changed the name of the standardized version to ECMAScript.
However, even with all these standardization efforts, supported in some cases by companies whose annual revenues exceed those of the entire book publishing industry, there are still incompatibilities among browsers, and even among versions of the same browsers. For example, Mozilla has JavaScript in its Firefox browser, and Microsoft still has JScript in its Internet Explorer. Both are compatible with ECMAScript at a basic level, but both have additional features that are incompatible with each other.
From Browser Wars to eReader Wars
eBook designers have a variety of formats that they have to work with: Amazon's .AZW (based on the Mobipocket format acquired by Amazon) and Kindle Format 8 (based on HTML5 and CSS with extensions), EPUB 2.X, Apple's iBooks (EPUB 2 .X with Apple's extensions), Kobo Color Content (EPUB 2.X with Kobo's extensions,) Nook Digital Replica Plus (EPUB 2.X with Barnes & Noble's extensions,) EPUB 3 (HTML5 and CSS3 with the IDPF's extensions) and PDF.To eBook designers, the word "extensions" is a synonym for "incompatibilities." Two different eReaders may perform the same functions, but if the tags or attributes that tell the eReaders what to do are even slightly different, eBook designers will have to either design around the differences or not use the functions.
Can we draw lessons for the eBook industry from the Browser Wars years? I think that we can:
- Incompatibilities among eReaders from different vendors, and even among different generations of eReaders from the same vendor, are inevitable and won't go away.
- Amazon will adopt EPUB 3 48 hours after Apple provides full support of Flash in iOS. In other words, it'll never happen. Amazon's eBook formats are strategic technologies for the company, and it won't allow any competitor or group of competitors to dictate how a strategic technology must work.
- Despite the best of intentions, browsers' implementations of HTML5, CSS3 and JavaScript are still incomplete, although they're much less incompatible than they once were.
- EPUB 3 is based on HTML5 and CSS3, and most eReader developers will either base their software and devices on an existing web browser to avoid "reinventing the wheel," or will use the customer's existing web browser and then support the EPUB 3 extensions with JavaScript. Either case makes EPUB 3 subject to lesson 3 above.
- In order to minimize time and cost, eBook designers and developers will inevitably gravitate to a "lowest common denominator" approach, where they'll either only use features supported compatibly by the largest number of eReaders, or will design eBooks so that features that aren't supported by a particular eReader are either simulated or ignored without crashing.
No comments:
Post a Comment