Apple yesterday unveiled iBooks Author, a free app that enables you to create multitouch books for the iPad. The application resembles products from Apple's iWork suite, and it is already mired in controversy, in part due to workflow limitations and a seeming lack of interest in typography, but also due to an EULA that appears to forbid commercial use of it for anything other than creating products to sell through Apple's own storefront.
Now standards advocates have honed in on another controversial aspect of Apple's new app: that it’s extending an existing standard with proprietary hooks.
Daniel Glazman, W3C CSS Working Group co-chairman, outlined the problems in a blog post and also spoke to us about his concerns with Apple's format, and also with the general reporting about iBooks Author.
"iBooks Author is not an EPUB3 editor as many journalists said,” he complained. “EPUB3 is a standard, and there is nothing between 'comformant' and 'non-conformant'. The *.ibooks format is based on EPUB3 but it's not a profile of it – it extends it, and so it's not EPUB3!
“This fragments the market, places a burden on the publishing industry, and creates a trap for customers, who can be sure their purchases through the iBooks Store will never be exportable to an EPUB3 reader."
Niche product
Glazman reckons this is a bad strategy for Apple. He thinks the company has released a great piece of software that could have been the immediate market leader, but through not being able to export nor import 'real' EPUB3, it will only fulfil a niche.
He's also unhappy with Apple extending EPUB3: "Apple's used things that do exist on the CSS WG radar but has diverged – sometimes drastically,” he argued. “Some extensions are based on old CSS WG working drafts that are no longer relevant, and properties/values explicitly dropped since that draft. Some others were never discussed with the CSS WG or never made it into a written proposal."
The net result, said Glazman, is that Apple now has two incompatible kinds of web documents: HTML documents for the browser and HTML documents for iBooks Author. "That's dangerous for everyone, including Apple users," he added.
We asked whether Apple's additions could be added to EPUB3. "I cannot speak for the IDPF consortium," replied Glazman, “but since EPUB has always wanted to include new CSS features that we work on and they need for the publishing industry, I just cannot believe they're not actively looking at our Layout, Exclusions and Multi-Column working drafts. So I think the features will eventually make it into an EPUB standard. But I'm not sure they would be based on Apple's implementation, which isn't yet even officially documented and conflicts with existing CSS WG documents."
Going it alone
On interoperability, Glazman told us he thought it was clear iBooks Author intended to "offer an editing environment for eBooks that is unmatched on other platforms, making the release of a book simple on the iBooks Store while it remains more complex on other platforms". But what has angered him most is Apple using EPUB as a foundation rather than Apple's end result of an effectively proprietary platform.
"The original plan for iBooks was probably to be fully EPUB compliant until the market started moving too quickly and became a threat for Apple. When Adobe released its Regions and Exclusions specs, Adobe became a competitor in Apple's space and Adobe InDesign is probably seen as a danger, able to boost all online bookstores and not only Apple's. Hence the new Apple release, based on proprietary extensions that are even incompatible with Safari."
Baldur Bjarnason, ebook developer and researcher was also unimpressed with Apple's forking of the EPUB3 standard. "Apple's inclusion of old, incompatible drafts of standards and a custom layout model incompatible with everything proposed by the CSS Working Group means it's next to impossible to convert an iBooks file to an EPUB3 file and maintain its design,” he argued. “You'd have to reimplement it from scratch."
Additionally, Bjarnason noted that the built-in widgets are proprietary and non-standard, "not implemented using JavaScript, but instead defined through custom object tags and data attributes that tie into private extensions to the WebKit browser rendering engine. These objects are technically standard HTML5 but would still be completely meaningless to a web browser or EPUB reading system."
According to Bjarnason, Apple didn't have to do things this way: "EPUB3 defines a backwards-compatible way of implementing widgets like this, called bindings, and there are implementations of the proposed standard for regions and text-wraps available for WebKit." He told us there's therefore no technical reason why Apple couldn't have implemented what it wanted in "fully standards-compliant EPUB3, using bindings for the widgets, and draft standards for the CSS layout, with sensible fallbacks for legacy readers". His conclusion: "Apple just didn't want to."
Apple did not respond to .net's request for comment on this issue.
