HTML5 in the world of DITA

My new blender has a programmed mode in which the ingredients initially swirl around just before it goes into a surge of power that brings everything together into something new. HTML5 is like that: buzz about this mysterious upgrade first came on our radars several years ago via preliminary demos and fuzzy projections for the future, but lately we’re seeing more articles about best practices for its use coming into place. HTML5 truly is becoming “cooked,” in developer parlance.

If you are coming to HTML5 from an unstructured content background, the talk about “semantic tags” can be confusing. For example, whether to use <aside> within or outside of the <article> depends on the semantic relationship of the marginalized content to the article or to the site itself. In a poorly information-typed language like HTML, these distinctions are indeed not very clear to most people.

Users of DITA, however, probably see some clear associations of these HTML5 elements with structures in both DITA topics and DITA maps. Topics, in DITA parlance, are directly equivalent to the content of the HTML5 <article> element, and maps are pretty clearly equivalent to the content in a <nav> element. But I was delighted to understand that there is a greater type of synergy as well between HTML5 and DITA: that topics and maps each have an almost-by-design relationship with the recommended layout of a web page based on HTML5 principles.

Most web page content, even that generated by the DITA Open Toolkit, is expected to be viewed in the context of some larger environment that provides affordances like navigation, site terms and conditions, “About” and “Help” pages, and more. The key thing about HTML5, as I see it, is that it formalizes the organization of these disparate types of content into the cohesive end-user view. Earlier versions of HTML could do that as well, but only by using <div> and <span> elements with a good deal of CSS to effect the visual arrangement of the parts, or by the more discouraged techniques of layouts based on <frameset> or <table> markup. The “semantics” of HTML5 now enable each of these page artifacts to be arranged within markup that better clarifies the intent of the content in each location, whether it be a set of navigation links or a list of categories off to the side. Most particularly, the oft-presumed header and footer regions of a displayed page now have formal markup identifying those respective chunks of content. The full set of new structural elements in HTML5 are: header, footer, section, aside, nav, and article.

“HTML5 authoring communities now have a reason to care about structure…”

And this plays well for DITA output rendering because these page layout regions correspond to overall DITA structures, both those implied by nested topics and by aggregated maps. Moreover, an emerging HTML5 feature called the “Document Outlining Algorithm” now enables browsers to infer map-like structure from HTML that has been properly constructed using fully nested sections with titles. Voila! Now the top-down processing normally generated for DITA content has a convergent browser capability that pushes HTML5 content creators to honor good principles of topic orientation and chunking. In other words, HTML5 authoring communities now have a reason to care about structure, and this portends greater future interoperability for tools like structured editors that can insert the best-practice wrappers for conforming HTML5 content.

HTML writers new to the idea are often confused about the role of these new structuring elements. HTML5 authors must make a conscious decision about how to designate various parts of the content as articles, sections, asides, or navs. Meanwhile, DITA authoring provides the proper structures (the design patterns missing in HTML) by default because XML editors auto-generate all wrapper markup needed for nested content in DITA. So basically, any “Simple DITA” authoring tool automatically becomes a boon for someone who needs to create semantically well-structured HTML5 because DITA provides the validated structure that maps directly to the HTML5 structures that for now can be enforced only by adhering to guidelines.

I’m not saying that the semantic names added to HTML5 have the same meaning as similar terms in DITA. <article> and <section> may have decidedly different meanings, and a topic can be either an article or an aside depending on context. How are you to know? It depends on your high-level information architecture and how it maps to the user’s view of the finished product, to some extent. I prefer to think of the HTML5 structural elements as a form of page-ordering language like XSL-FO rather than as author-guiding structures as enforced by DITA’s schemas. In this sense, it is now possible to organize and play back any DITA-based web page for better quality to other outputs such as ebooks and PDFs by viewing these HTML5 elements as formatting objects in their own right, upon which you can now differentiate your ultimate rendering, whether it be in a browser or to a CSS3-styled PDF page.

In this world of potentially good possible outcomes, I foresee:

  1. Replacement of the tri-pane layouts of DITA Open Toolkit by style-based layouts that internalize the layout into the display context. In other words, simpler site maintenance.
  2. More use of DITA as direct-to-browser based content, particularly when either the map or the outer topic of a composite topic is used to organize the user’s view of that content architecture.
  3. The increased use of CSS3 printing stylesheets and corresponding transforms enabling HTML5-based output to print beautifully and without the transform headaches usually associated with XSL-FO based PDF generation.
  4. New DITA specializations that exploit these capabilities. Eliot Kimber, for example, has started looking into HTML5 output from his DITA for Publishers specialization–I can see this as a basically new toolkit specifically for commercial publishing workflows for all types of original DITA content. Another exciting use would be a composite/aggregated DITA structure that plays well into the more general case of business oriented documents–creating single-file whitepapers in a Word-like SOHO or SMB environment, for example.
  5. Perhaps the increased recognition of the power of DITA’s organizational design patterns by the HTML5 working group, with some future intersections becoming possible in time for DITA 2.0 to accomodate them.
  6. Enabling more consistent inclusion of videos, images, and other non-text content as titled exhibits within an HTML page. I’ve seen this as one of the most frustrating things for writers to maintain in the absence of guidance from the editing tools.
  7. And most exciting from my viewpoint, potentially seeing the vision of DITA being used by web content authors because of the guidance it provides for the structures they need to generate for their published HTML5 blogs and site pages. I’m still pushing for the basic free DITA editor that can lead Web authors into this structural Nirvana, but I’m very hopeful for the future of the commercial tools that are already at hand for these future consumers.

I’d like to hear your thoughts on how DITA relates to HTML5 and how both can be exploited for mutual benefit!

Related topics:

Opinion: And by the way, I prefer <aside> to <sidebar> in that ongoing debate–what is a sidebar on a web screen may be endnotes in a printed presentation, even though both types of content are still “asides” from the discourse itself. I prefer to associate the presentation to the generic structure at rendering time, thank you. Either is more  preferable to <div class=”sidebar”> which has been the table-free workaround before.
This entry was posted in Analysis and tagged , . Bookmark the permalink.