In the past six years, the rise of the ebook has ushered in three successive revolutions that have roiled and reshaped the traditional publishing industry.
Revolution #1 began in November in 2007, when Amazon released its first-generation eInk Kindle. As the first ereader to achieve broad adoption by consumers, the Kindle fundamentally changed our answer to the question, “How do you read a book?” On paper? Sure. But also maybe on a handheld screen!
Revolution #2 began in January of 2010, when Apple released its first-generation iPad. As the first tablet computer to achieve a critical mass of popularity, the iPad fundamentally changed our conceptions about what those handheld ereader screens could and should do, and as a result, it raised a deeper metaphysical question: “What is a book?” An immutable stream of text and pictures? Sure. But also maybe audio, video, and elements like 3-D models, games, and quizzes that respond and adapt to human interaction!
But I’m currently most excited about Revolution #3, which just started to take hold in early 2012, when folks deeply invested in the implications of Revolutions #1 and #2 started asking, “How do you create these postmodern books that contain more than just text and pictures, which people will read on eInk ereaders, tablets, and smartphones?” From this question sprang tools such as iBooks Author, Vook, PressBooks, and Inkling, which all attempt to tackle one or more facets of this problem.
But unlike the first two revolutions, in my opinion, Revolution #3 isn’t really defined by a new piece of hardware, software product, or platform. Instead, it’s really marked by a dramatic paradigm change among authors and publishers, who are shifting their toolsets away from legacy word processing and desktop publishing suites, and toward HTML5 and tools built on the Open Web Platform.
At the Balisage Markup Conference 2013, I presented the paper “The Case for Authoring and Producing Books in (X)HTML5,” in which I argue that the HTML5 platform provides three key advantages to authors and publishers looking to create and produce books in the brave, new digital world. HTML5-based authoring offers a streamlined production workflow for producing both print and digital outputs, facilitates “digital first” content development, and is a perfect fit for creating a WYSIWYG, Web-based writing experience.
HTML5: Both Source and Output Format
The Achilles’ heel of many a publishing workflow is the depth of its reliance on file conversions to transition back and forth among requisite source and output formats. Getting an author’s Microsoft Word files into Adobe InDesign so the publisher can do the graphic design and typesetting entails a conversion. So does taking those InDesign files and outputting HTML content for embedding in an EPUB or Mobi package. Every single one of these conversions offers a fresh opportunity to consume valuable human resources and/or introduce errors into the content. But regardless of their accuracy or automatability, I argue in “The Case for Authoring and Producing Books in (X)HTML5” that every single conversion in a publishing workflow incurs an unavoidable cost:
If conversions are outsourced to another vendor, the cost is in both dollars and time. If conversions are automated in-house, the cost comes in the form of the human resources on staff required to maintain the codebase. As such, the ultimate goal in creating streamlined publishing workflows isnâ€™t solely to lower the costs of conversions whenever possible; the aim should also be to eliminate the need for conversions whenever possible.
What HTML5 offers is an escape hatch from a publishing workflow weighed down by conversions, because it’s possible for HTML to serve both as canonical source format and output format for book content:
A huge asset that HTML5 offers as a book authoring format is that unlike Microsoft Word or DocBook, it is not just an authoring format: it is a hugely popular output format. Aside from the fact that HTML is inarguably the dominant markup for content published on the Web, it is also at the core of both the EPUB and Mobi ebook formats. As a result, if HTML5 is used as the source manuscript format, the task of producing ebook outputs is reduced to one of styling the content (with CSS) and packaging it as appropriate for distribution…
And what about producing print books? It may be counterintuitive, but HTML5 is actually an excellent source format for producing paginated content, as the CSS3 Paged Media Module can be utilized to design the eqiuivalent of a standard book template for print. Features supported in CSS3 Paged Media include page headers, footers, folios, crop marks, font selection, distinct master pages for verso/recto/chapter-opener pages, and even a good deal of control over pagebreaking via both explicit instructions and widow/orphan controls….Itâ€™s now possible to take an HTML5 manuscript and a CSS3 stylesheet including paged-media rules, and run it through either tool to get a high-quality, print-ready PDF file.
Authoring book content in HTML5 thus allows for a maximally streamlined, lightweight workflow for producing books, which is a boon both in terms of cutting costs and time to market.
HTML5 and “Digital First” Content Development
Anyone who truly wants to engage with the challenge posed by Revolution #2 and be a part of evolving the medium of the “book” needs to take seriously the notion of digital-first content development. Being digital first means refusing to make the ebook version of your content an afterthought. The digital format of the book should not be merely a postproduction conversion of print-bound manuscript files; nor should it be an ex post facto “enhanced” version of content that has already been completedâ€” for example, adding in a few video clips at the end of an otherwise static text. From conception to publication, true digital-first content is designed to take full advantage of the capabilities offered by dedicated ereaders, tablets, and smartphones to create something that is native to the platform.
There is no other source content format better suited to the task of developing digital-first content for the diverse ecosystem of ereading devices than HTML5, because you can develop directly for the browser (ereader software engines are effectively specialized Web browsers). As I argue in “The Case for Authoring and Producing Books in (X)HTML5,” authoring in HTML5 makes it “trivial to integrate…digital-first elements directly into the manuscript”:
If you opt to use traditional word-processing and desktop-publishing tools to author a book with special digital features, youâ€™ll be faced with questions like, â€śHow do I embed a Canvas in my Word doc?â€ť, â€śHow do I change all those image placeholders into video files for the ebook version?â€ť, and so on. The answer: more scripting or manual markup rework, either as part of the conversion or as a postprocessing step….
In contrast, HTML5 was expressly designed for the purpose of marking up digital media, and the ebooks you produce will use HTML5 to render it. Choosing to author the entire book in HTML5 just makes sense…”
HTML5 and WYSIWYG, Browser-Based Authoring
The popularity of cloud-based services like Google Docs is a testament to the value offered by online, browser-based document editing. Storing and editing documents in the cloud facilitates easy collaboration among authors, editors, and production staff, and eliminates much (if not all) of the overhead otherwise entailed in installing/configuring requisite software on all contributors’ PCs and trafficking files back and forth between them.
But just as valuable as a cloud-based authoring platform is one that offers a true WYSIWYG editing experience. I state in “The Case for Authoring and Producing Books in (X)HTML5” that
By WYSIWYG authoring, I not only mean that when content is tagged to be rendered in italics, the content onscreen actually appears in italics (as opposed to being displayed as
<emphasis>in italics</emphasis>). WYSIWYG should mean that the onscreen display mirrors as closely as possible what the final product will actually look like. In a model where a book manuscript is written in Microsoft Word and then composited in Adobe InDesign, this is rarely the case. At best, the onscreen display in Word is usually a rough approximation of how the content will end up looking when the real template is applied in InDesign. Thatâ€™s not a great model when youâ€™re looking to quickly iterate on both content development and typesetting.
HTML5 is an ideal technology on which to build a WYSIWYG, browser-based authoring platform:
The cornerstone of the WYSIWYG HTML5 editor is the
The HTML5 Tools are Coming!
I expect that the coming year will bring continued growth and innovation in the sphere of HTML5-based software tools for publishers. In June of 2013, the W3C launched the Digital Publishing Interest Group with the goal of bringing together publishing veterans to work on bridging the gap between the needs of book/journal/magazine publishers and the technological capabilities afforded by W3C specifications.
At O’Reilly Media, as we work on transitioning to an XHTML5-source* workflow (which will be the cornerstone of the next release of our Atlas publishing platform),** we have posted an open source project on GitHub called HTMLBook. The HTMLBook project contains an XML Schema that subsets the HTML5 content model to provide specifications for book-specific semantics, such as chapters, appendixes, and sidebars. Additionally, it contains a sample CSS stylesheet for styling HTML5 content for PDF output using CSS3 Paged Media, and XSL tools for autogenerating book navigation elements including tables of contents, indexes, and cross-references, as well as generating the necessary metadata and package files for EPUB 3 output. We look forward to continued collaboration around the development of HTML5 authoring tools for publishers.
* Conforming to the additional constraints required to make our HTML5 content well-formed XML enables us to manipulate it with XSLT, which is an integral part of our toolchain for generating ebook outputs.
** In an upcoming post, I will discuss in more depth O’Reilly’s shift from a DocBook-source workflow to an XHTML5-source workflow, and how we’ve architected our new publishing toolchain.