HTML5 is the Future of Book Authorship

The key advantages of the HTML5 platform for authors and publishers

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.

Spread from O’Reilly’s Encylopedia of Electronic Components Volume 1, which was composited with HTML5 and CSS3

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 _in italics_ or <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:

If you need to construct an authoring frontend in HTML5, CSS, and JavaScript to get it on the Web, why not just accept the manuscript files in HTML5, CSS, and JavaScript as well? That means no additional interpreters are needed to render the source content in the editor for WYSIWYG display.

The cornerstone of the WYSIWYG HTML5 editor is the contenteditable attribute, which, when set on any element in a HTML5 document, allows the interior content of that element to be dynamically edited in real time by the end user who loads that document in her Web browser. With the help of some JavaScript to allow manipulation of contenteditable elements via a GUI interface (formatting buttons, etc.), and CSS to provide the appropriate styling of the added content, it is possible to create the analog of an InDesign template right in the Web browser, where the user can write and composite a manuscript without having to manually modify the HTML source or CSS stylesheets.

A plethora of open source, contenteditable-based GUI HTML5 web editors have been created in this fashion.

CKEditor is an open source, browser-based WYSIWYG HTML5 editor

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.

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
• Marbux

Sounds great until you get to the part you left out: interoperability of editing software. HTML5 is a broadcast format, signed for the one-way transmission of data. Getting those snazzy editors to talk to each other will be an entirely different story.

• James

If you are building editors using the HTML5 standards for rendering content, then there is no issue with each editor interpreting the information differently because the information is contained in the same format regardless.

This is quite common place even now when you use WYSIWYG editors on most sites. Switching editors these days does not create the stack of issues it used to as editors are becoming smarter and utilizing more common standard approaches. With time, i would imagine that this will get better as all editors will use the same common formatting as defined by the HTML5 document standards.

• Morgan McGuire

“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?”

Like this: http://graphicscodex.com.

I tried many of the tools mentioned in this article and found them still wedded to traditional page-based layout, linear reading, and hard-coded formatting. iBooks Author doesn’t even have native equation support–a serious constraint for writing any science book! I made my own HTML5 solution using HTML, CSS, Javascript, and XML to implement a full LaTeX typesetting system with interactive controls and dynamic layout.

• Charley

What are you using to render LaTeX? MathJax?, is your system open sourced?

• Morgan McGuire

Yes, it uses an extended version of MathJax to drive equation rendering and then processes listings, figures, and body text in an XSL interpreter for LaTeX. I released many of the enabling pieces of Javascript as open source in codeheart.js, but not the LaTeX interpreter which is specific to my application.

• Charley

That sounds awesome. the interactive controls is something that I was looking for with LaTeX.

• Ken

https://simplebooklet.com/ is an interesting example of an application targeting this space.

• http://devtools.korzh.com/ devtools.korzh

Thanks! Good examples

• fleur12moz

The fact that HTML 5 has standard set of tags that everyone uses makes it a good tool for book publishing.

• http://duncanlong.com/art.html Duncan Long

Very interesting concept. HOWEVER, as a professional graphics artist I’m horrified by potential giant leap backward that might occur if
the software now used for print layout is replaced by some cobbled
together HTML editor created by software engineers who refuse to consult
users and experts. Word and other office software suffers from this as
do many web page editors.

There are conventions in book layout that are
very subtle, and I fear know-it-all engineers are likely to be blissfully
unaware of the layout guy’s needs (or, worse, assume they know better
than he does what those needs are). In the end, software engineers are
amateurs at layout and should not have the final say on how the software
works and what it does, with many of these conventions having developed over hundreds of years (and therefore both perfected and expected — whether on the conscious or subconscious level — by both those putting together books as well as readers).

BUT I would most certainly welcome one piece of software that could handle
print, ebook, and web page layouts (provided it is really for
professional layout as noted above). That would be a dream come true.

• Otto Akama

Your concept is a reality check, hence with the right people involved, things can always be arranged. Plus if things come up and they are not loved, it creates opportunities for entrepreneurs to design better HTML tools, designed with the standard design practices that will wow customers and the world goes ahead.
When standardization bodies fail, entrepreneurs take a lead.

• http://duncanlong.com/art.html Duncan Long

I understand what you’re saying, and over time this may be true in many cases. Yet today’s ebook is the perfect example of how things can run amuck: Software/hardware designers set the specs for the Kindle format (and the same is pretty much true with the EPUB format as well), and generally the results proved a giant leap backward in book layout design, far from elegant and often quite crude if not ugly. And the features and options needed to make designs less so remain non-existent and have been for years. No one has stepped up to the plate to fix this, and the “it’s good enough” philosophy in laying out Kindles continues years later. It’s that sort of thing that makes graphic designers and publishers shudder at the possibilities of software designers devising new editing/layout programs without proper input from truly professional graphic designers.

• Otto Akama

Thanks @DuncanLong:disqus. Very true. Very very true. If you read Robert Green’s 48 laws of Power, you could see his opinion of “Every game is a power game”. If developers are changing the turn of events and affecting industry and consumer tools, the truth is, they cannot be stopped because of their excessive willingness. If designers want to affect this change to maintain and improve design standards, then they should join and lead some of these industry revolutions led by developers. Creating cool designs is no power. Using those cool designs in a project that affects people’s lives is power. Designers should take it to be leaders, not just partakers in teams and when decisions concerning the release MVPs and product versions, then it will be awesome.

And I believe that out of every 100 tools created the top 5 will be tools that an elite designer was actively part of it.

• http://duncanlong.com/art.html Duncan Long

In an ideal world, designers would be on the development team; possibly some are with some companies — but even with those, I would bet the designers are pretty green rather than seasoned pros that know the finer tweaks and tricks. Worse, software engineers tend (as near as I can tell) to see potential users are “the problem” or even as “the enemy;” seasoned pros are “dinosaurs” to be ignored (if not scorned). The result is a sort of “take it or leave it” attitude by those creating software when presenting it to the community that will use it. Perhaps that’s not always the case, but too often it surely seems to be true. Certainly I know of no well-known graphic designer who has ever been asked to take an active part in software design — and I would bet any such designer offering to “join and lead” would be soundly rejected. I would be happy to be wrong in all this, but as more and more design software comes down the pike with poor human engineering and missing key features (or features buried in menus), I think I’m likely at least close to the mark.

• Otto Akama

Hmm! I see. Then innovation is losing great opportunities with designers not at the lead. Engineers are disruptive and to the best of my knowledge, so are artists. Designers could team up and correct the mistakes of products build by engineers by replicating it with the human being in mind. I believe that if a designer initiates a project, he won’t let engineers come in and dictate to him/her.

• http://duncanlong.com/art.html Duncan Long

I don’t think it is a matter of dictating so much as creating an elegant tool to make the creative process easier for the user. Sadly (as you note) there is an overabundance of pride and “disruptive behavior” in both groups and that can get in the way. However being known for the person who created a truly useful and loved tool is a goal worth pursuing. Possibly one “fix” would be giving those involved in creating software more honor and credit. For example, surely the people involved with InDesign, Photoshop, etc., all deserve some recognition — and yet I’ve never seen even a word about all those involved.

• Otto Akama

I am glad to have gotten some insights from you @DuncanLong:disqus. I love design and I hate the fact that designers are not at the lead of tools like these. I have been to your http://www.duncanlong.com/ and from there, I see your point even clearer. This is an entrepreneurial opportunity for authoring tools, as the one that will built with designers on lead will definitely win. That’s a concept which has been proven again and again. Nice meeting you.

• http://duncanlong.com/art.html Duncan Long

Thanks for the kind words, Otto. I appreciate your candor and optimism — and hope that you’re correct in your assessment of things.

• Otto Akama

You’re welcome

• Guest

And I believe that out of every 100 tools created the top 5 will be tools that a good designer was actively part of it.

• yelvington

This is “back to basics.” HTML derives from SGML, which was created in the 1960s to facilitate printed text.

• InklingBooks

Duncan Long is right. Those who’ve been involved in HTML have never shown much interest in creating attractive webpages (just complex, cluttered ones). It seems a bit of a stretch to see them develop an interest in creating attractive printed books.

I also suspect that InDesign has a large enough head start, that any HTML startup application simply won’t be able to catch up. In fact, I’m quite impressed with just how well InDesign 6.0 can handle both print and digital outputs. By the time these HTML 5 tools arrive, it’s be still further along.

–Michael W. Perry, My Nights with Leukemia: Caring for Children with Cancer

• pedro_galvan

I am the editor of a small magazine. We have different collaborators for each issue and all our collaborators are voluntaries. Our workflow goes something like this:

1) Google Docs is our base text editing tool. This provides us with version control and collaborative editing. Besides the text, in Google Docs we also apply basic formatting styles (paragraph, heading, bullet lists) and add content relevant images (diagrams, tables, etc that are referred in the text).

2) We send the contents to InDesign (relying on the DocsFlow plugin to keep texts in sync with Google docs). In there we lay out the magazine properly, and basically make it pretty (set colors, special fonts, add extra images that are not referred in the text and are just used for decoration), and add the ads (oh yes, somehow we still have print ads).

3) From InDesign we generate a couple of PDFs: one to send to print (cmyk high res with bleed) and one for online viewing (RGB at 150 ppi).

4) In order to generate the ebooks, we don’t rely on the InDesign version because it applies lots of stying and layout for which we don’t care in a kindle-type ebook. So, we go back to the Google Docs and copy-paste the articles into a tool like Sigil, and then generate the epub and from that generate the mobi for Kindle. I suppose that there must be a smarter way for doing this, but haven’t had the chance to research it (if you have a suggestion please send it my way).

Anyway, after all this explanation, what I want to say is that I strongly believe that there is a case for html-source editing and publishing, especially for small/independent publishers like ourselves that don’t have a controlled staff of writers/editors. In cases where design is an important part of the product (like in magazines) it would be far fetched to do everything from an html editor, you still need a desktop publishing tool. But if that tool is properly linked/synced to the html sources, that is a great help.

In our case, we are somehow doing it but can see lots of opportunities for automation, sync and better asset management. I’ll be sure to try out the Atlas authoring platform when it is available.

• Sanders Kleinfeld

Thanks for sharing your workflow @pedro_galvan. Stay tuned for more announcements re: Atlas in the coming months!

• Georg Stadler

How do you adress hyphenation for print?

• Sanders Kleinfeld

@georgstadler:disqus, CSS2/CSS3 provides properties for dealing with hyphenation and pagebreaks. We use the “hyphens” and “word-wrap” properties to configure linebreaks, and the “widows” and “orphans” properties to configure pagebreaks. We use the Antenna House Formatter (http://antennahouse.com/) to generate PDF for print, and this software provides additional fine-grained control over hyphenation with a hyphenation dictionary.

• http://blog.tianakai.com/ Tiana Kai

Agreed! It’s such an exciting time for publishing…with HTML5! This is why I am happy to join the ranks along with my team. We recently launched Papermine’s public beta – http://papermine.com – we’ve been extremely pleased with the positive feedback!

There is an incredible amount of benefits relating to the fact that Papermine was built with HTML5, so here are a few pros that I would like to share: 1) read our digital magazines offline on a ‘crowded commuter train’ on any browser or device 2) choose from the wide variety of themes that can also be personalized in the easy-to-use editor 3) the Facebook app gives authors/bloggers the opportunity to share their digital shelf on their fan page 4) easily insert advertising 5) There are many more features and benefits, so feel free to check us out at http://papermine.com/examples/ and let me know what you think!

Let me know if you check it out! To provide you with the best experience check it out on an iPad and on modern browsers (Chrome, Firefox, Safari); soon to be optimized for Android.

• Katherine Fletcher

I totally agree with all of these reasons for using HTML5 for book authoring! In fact, I have a fellowship with the Shuttleworth Foundation to do just that for textbook authoring. We have been following OReilly’s work on HTMLBook closely and are very excited about the convergence of ideas. We have a fork of it called TextbookHTML.

And (shameless plug coming) check out our open-source, wysiwyg HTML5 editor for textbooks, currently named github-book. This blog post contains links to demos, the source code, and our UI designs (http://kefletcher.blogspot.com/2013/09/more-about-textbook-editor.html).

The editor automatically creates EPUBs (for mobile viewing), saves textbooks to
github for sharing and repurposing, and supports mathematics and
textbook features like notes, examples, equations, and homework problems.

• Stuart

I like the concept of HTML5 for single source. Whether in reality it’s viable now… I don’t know. Can someone please point me in the right direction re state of the art for large online books. Previously used XDK, but it is defunct and maybe Robohelp is worth investigating? Need:

• Stuart

Need:
* tracking TOC (tree of table of contents like bookmarks panel in PDF, but sexier and it actually updates to display location as you click around the book eg. by following a cross-reference
* ability to handle footnotes (end notes impractical)
* ability to handle “print quality” layouts, including complex tables and images
* ability to support desktop and mobile

No current requirement for print output, but single source support for that would be a bonus.

Please suggest tools I should investigate.

Stuart

• Francis Shum

Stuart,

You may take a look into ConstEdit that is mentioned in my previous comment.

Concerning your requirements:

* tracking TOC (tree of table of contents like bookmarks panel in PDF,
but sexier and it actually updates to display location as you click around the book eg. by following a cross-reference
- that’s exactly the Sections Outline Dialog in ConstEdt

* ability to handle footnotes (end notes impractical)
- ConstEdit supports just endnotes

* ability to handle “print quality” layouts, including complex tables and images
- you may need some testing to see if the app is up to your standard

* ability to support desktop and mobile
- the app only runs in the desktop mode of Windows.

• Francis Shum

Agree 100% that html5 should be the future. “ConstEdit” is just such a word processor for writing documents in the html5 format. While it is certainly not sophisticated enough to be utilized for book publishing, it certain has the full capabilities for daily business & personal documentation purposes. It makes full use of the sectioning elements in html5 to provide its section management functions.

Disclaimer : I am the author of the ConstEdit editor.

• Richard Dickinson

Nice article..thanks (BTW the print button link for this article opens a completely different article on O’Reilly programming to this article so is useless! The joys of printing..)

• nc_mike

Interesting. Can this approach handle forward and backward references for a book model output? I recall that some things such as creating partial tables of contents, complex indexes and so on require multi-pass processing for full resolution of these types of things for printed books.