All Workflows Lead To HTML

Introduction

XML was initially designed as “SGML for the Web”. While there is no doubt that this was a highly meritorious vision, it is a rather simple fact that — at least where client-side Web technology is concerned — it has failed to come into existence. Furthermore, that fact is not about to change. On the contrary, the entire client-side stack of Web technology has moved away from XML almost entirely, and will continue to do so for the foreseeable future.

This can at first seem unsettling, if not downright worrying, for those who have invested in XML, often primarily on the server side. There is also often a perception that the promises of interoperability made by XML will be exterminated in an HTML world, supposed to be unprocessable, messy “tag soup”.

So are we doomed? Must we throw all that XML brought to the table out through the window? Are we condemned to a choice between managing a chaotic format or cloistering ourselves up in a small irredentist community of XML increasingly detached from the world? This paper's position on each of these questions is a resounding “No”. It is, however, necessary to understand where the technological landscape is headed, and accordingly to make course corrections in some aspects.

Nothing is Lost

First of all, the vision of full interoperability and distributed extensibility remains. In fact, it is stronger than it has ever been. It is coming to fruition, albeit not in the way initially envisioned by the XML project.

HTML is no longer a “tag soup” language. Following a Herculean effort, its parsing has now been fully defined, in a manner that remains compatible with the vast amounts of existing content. The level of interoperability between implementations is extremely high, and their performance is overall excellent. The one lesser spot (that is being addressed) is that HTML parsers for server-side languages are still lagging. But as we will see below, that is not a cause of concern for the topic that occupies us here.

XML had grand plans for distributed extensibility built atop namespaces, that were expected to enable compound document formats, distributed discoverable implementation, and semantic safety, but for the most part this system barely evolved beyond the syntax level and never reached the hard problems of integrating distributed behaviour. Even for relatively simple aspects such as validation, existing XML solutions are poorly equipped to face distributed extensibility; the only viable solution is NVDL and very few people ever use it.

In the meantime, HTML is tackling precisely such difficult issues through the ongoing work on Web Components. While it is still too early to call it a success, the first implementations are promising, there is a lot of momentum behind this approach, and it certainly is offering solutions to these hard problems.

My point here is not to belittle XML or to argue for its dismissal across the board in favour of HTML. Rather, I believe that as a community we need to align our expectations on reality in order to better plan for the future through the technologies that we develop.

XML has been and remains a very strong solution to capture and process disparate information with variegated structure, and is particularly good at encoding textual content. It benefits from a solid ecosystem of tried and true tools that often surpass those available to other systems. On the client, however, we need to agree that it is quite simply dead. HTML on the other hand now provides for an extremely powerful client-side platform that is unrivalled in its power and richness.

Based on such updated expectations about each technology, I believe that it is clear that the two are complementary, and that publishers who are already heavily invested in the XML tool chain can greatly benefit from the alliance of both.

Harmony

The prospect of deploying two technologies instead of one may at first seem daunting. Will it not incur greater complexity? We will look at why HTML is in fact a simplification over XHTML in the next section, but first consider the following piece of code:

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"
              doctype-system="about:legacy-compat" encoding="UTF-8"/>
  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>
        

If you have an existing pipeline that is already producing XHTML, tacking this simple XSLT 1.0 style sheet at its end is all you need in order to switch your production processing to HTML. There is nothing complicated about it, it ought to execute rather quickly in most modern processors, and of course instead of an extra step you can simply modify the xsl:output of a preceding sheet.

The amount of work required in order to evolve the XML production pipeline is therefore as minimal as it gets. Keep the XML, just output HTML.

Don't Judge A Book By Its Markup

At this point the astute reader might ask: “Wait a second… why not just use XHTML then?”

There are two primary reasons. First, XHTML is not simply “HTML in XML”. There are differences in the way in which it gets processed in the browser, and while efforts have been made to keep the delta to a minimum, it is still there, and there is no doubt that if you ever author XHTML with the expectation that it will behave exactly like HTML, that delta will come back to bite you in the debugger.

Second, it is important to understand that developers of tools and libraries created for Web content rarely, if ever, test for XHTML. A lot of the time, they also don't care about XHTML-related issues when they are reported.

This can quickly become a problem when for instance interactivity is added to content through the use of JavaScript libraries. A good example is jQuery, which can at times work fine in XHTML mode and then all of a sudden blow up in an inexplicable (and hard to debug) fashion at an innocuous-looking line of code that seems no different from the ones around it.

That is the reason why using HTML on the client side reduces complexity compared to using XHTML. XHTML is used on the client so rarely that whenever you do anything ever-so-slightly out of the ordinary the odds are good that you are the first one to do it. And the only thing that comes from exploring such obscure code paths is not the glory of discovery but solely the pain of booby-trapped corridors. Readers already suffer from enough interoperability issues on their own; there is no need to make the problem worse with XHTML.

The problem also applies in reverse. Solutions designed to work with XHTML, for instance ones that make use of namespaces, will not port well to HTML. This effectively locks ebook content off the Web and prevents its natural evolution into an integrated Web in which one seamlessly navigates from page to book to app. This also means that the broader Web community is not taking part in solutions designed for what then becomes the ebook silo, which in turn deprives them of a vast reservoir of support and innovation.

Note that when I discuss XHTML in this paper, I mean real XHTML, which is to say served as application/xhtml+xml and processed using an XML parser. That is different from using polyglot markup, which may be using XHTML syntax but is processed by browsers as if it were HTML, thereby leading to no differences whatsoever. Polyglot can be somewhat useful in some specific situations, but it should not be prescribed as a silver bullet.

Client of the Future

Having established that server-side tool chains built on XML are safe and sound for continued use, but that using HTML on the client-side is much preferable, we now need to look at what needs to be done in order to migrate to this more reliable and future-proof setup.

Changes to ePub will be required in order to make it fully HTML-based and ready for complete convergence with the Web. On this I offer that all relevant parties cooperate in order to address each issue one by one, in an evolutionary manner, so as to ensure a smooth transition. It is likely that some new generic HTML-based solutions will be required in some cases; I would be more than happy to help contribute to their development.