What HTML5’s most-discussed benefits mean for DITA

While some of the new features of HTML5 have a direct bearing on its future relationship with DITA (per my previous two posts on the subject, What HTML5’s parsing algorithm means for DITA and What HTML5’s outlining feature means for DITA), its other new features tend to be featured more often in other blogs and discussions. I’ve just done another pass through the list to see what I was missing. A few features relate in some way to DITA content, but I’d categorize most as relating to Web development and general end-user benefits.

Markup features

Simplified doctype: The former XML-informed rigor for the XHTML doctypes is strongly eschewed in the HTML5 ruling class. They felt that the burdens of invoking validation and requiring browsers to stop working on invalid content were frankly draconian (and from an end-user’s perspective, I agree). Users should not have to bear the error messages normally meant for developers. So the two-pronged approach now is to define how parsers should deal with invalid content (the subject of one of my previous blogs) and to relax the doctype so that standard XML-based validation is not invoked, yet with enough structure to still turn on standards mode in the browser. So for now, the doctype in HTML5 is just <!DOCTYPE html>. If authoring HTML5 directly, you should still perform XML validation on your saved content (an XML DTD exists, although disdained by the ruling class), and, if generating HTML5 as output from DITA or other XML source, I believe that you should still use XML-compliant markup traits in your output transforms to HTML5 (closed singleton tags like <br/>, and proper nesting). It hurts nothing, and makes your generated content more consumeable by XSLT-aware web services.

Simplified attribute markup (no quotes required): This is a concession to content writers who use flat editors and create tag soup unthinkingly. If you are following the previous recommendation to generate standards-compliant XHTML conventions, you will be creating quoted attribute value declarations, so this non-progressive markup relaxation should not apply to you, and your standards-compliant markup certainly won’t harm any end-users or content consuming services.

Enhancements to forms: Several features relate to providing handy new features for forms, such as native syntax checking for email addresses, providing placeholder text behaviors within input fields, sliders for representing progress or ratings (3 out of 5, for example), and denoting required fields with browser-based checking (reducing the reliance on JavaScript for such input validation). These features should appeal to HTML5 app developers, but it’s not clear to me that DITA today has any direct representation for such markup (unless through a forms specialization, which is not out of the picture).

Inherent support for video and audio inclusions with brower-generated controls: For developers, this simplifies some of the former need to encode all such multimedia references using the <object> element. For DITA authors, nothing changes on the authoring side, but the transforms may now produce the simpler <video> markup with must less accompanying code for managing the UI aspects of that content. All current browsers support this markup, which puts pressure on IT organizations to urge their users to get with the latest browser versions.

Interactive content markup: <mark> (for applications to insert highlighting for search terms in context, for example), a “data-” prepend value for recognized user-declared attributes (use data-outputclass=”myspecialvalue” when preserving aspects of DITA meta-information in your HTML output, for example), <output> (sort of an Eval() placeholder for JavaScript dynamic result values such as timestamps), and more. Insofar as the spec is still under design and active beta, features may come or go, so this list may vary. Again, I see these as more for app development, but could be represented by appropriate DITA specializations at some point.

Depending on how you categorize markup, some of these could be viewed as semantic inline elements. I’ve chosen to call them “interactive content” markup because they tend to cause behaviors on the page vs actually representing the semantics of the content (other than a new <time> element whose behaviors are still being worked out).

Interoperability with other standards and web features

While interoperability with web standards is generally expected of browsers, Web developers have had to encode browser-specific overrides for including SVG or MathML snippets, for example. HTML5 does not specify interoperability practices, but the rollout is expecting all players in Web standards and services to play nicely together. Among the kinds of best practices that you’ll see emerging within the HTML5 ecosystem, watch for emphasis on:

SVG and MathML, some XML content fragments that are commonly embedded in HTML pages

CSS3, which enables many of the expected presentational aspects of what is considered to be “Web 2.0-ish”features–rounded corners for boxes, for example.

CSS3 is even providing some AJAX-like behaviors for dynamic content, enabling lighter solutions, even some degree of game-like behaviors using canvas and other graphic properties.

Geolocation capabilities should certainly be available within HTML5-class browsers. This is not an HTML5 capability, per se, but with HTML5, you can certainly build location-aware behaviors.

Local caching is also mentioned as if it were an HTML5 feature, although it is actually more of a browser feature that happens to make better use of what are now accepted web development techniques for making best use of bandwidth.

One of the most exciting capabilities that we’ll see emerging as a result of this increased interoperability of standards and services will be for creating interactive content on small-form-factor and touch-operated devices such as mobile phones and tablets.

Support for mobile form factors

HTML5 for mobile content may revolutionize pushing DITA content more easily to mobile devices. Most of the interoperability capabilities will apply directly to how you generate DITA content for use on mobile devices (geolocation, caching, UI features, and more).

HTML5 for mobile web content is basically the focus on generating DITA content into a form that provides more agreeable user experience, both in formatting for a small screen and for how links and controls, tables, and other problematic content are used in that context.

HTML5 for mobile apps on the other hand is more of a Web developer focus on creating mobile interfaces to major web sites (or for locally cached data for offline use) that are expected to revolutionize the cottage industry of app development. I’m speaking beyond my experience here, but I understand that instead of installing (and continually updating) an app to interface to my favorite world news site, a mobile web site will be able to provide the same behavior through the browser.

Impact to the DITA Open Toolkit

Here are some things that can be done now by developers who are interested in extending the DITA Open Toolkit’s capabilities with HTML5:

It is time to move on from the frame-based navigation shell provided in DITA-OT. Rather, include your individual result pages in the content pane of an HTML5-based structural shell, using the <header>, <footer>, <article>, <nav>, <aside> and other structural block elements per emerging best practice.

Devise alternate shells that specifically address best practices for mobile devices (cell phone and tablet buttons and layouts, for example)

Combine these HTML5 shells (the overall structure of your web site or content-rendering environment) with the appropriate use of CSS3 for layout control and to replace former box and image hacks for rounded corners, shading, offsets, etc..

Prefer the use of PNG for your graphics formats. JPEG and GIF formats are reliable, but have their quirks. PNG images are generally light, offering the best compromise of pixel accuracy vs compression artifacts of both other formats, and brands your site as using progressive standards.

Help write HTML5-specific overrides and documentation for best-practice use of the <object> element to represent HTML5’s video and audio function.

Provide support for inserting user-generated attributes (prefixed with “data-“) for outputclass and other DITA-specific metadata values we might push into the generated HTML.

HTML5’s structural markup works wonderfully well with CSS3 for creating various layouts for delivering transformed DITA content in exciting new ways. I’m looking forward to discussing some work I’ve done and to seeing the work of others in this area. DITA’s plain-Jane days are nearly past–HTML5 and CSS3 are about to put lipstick on this pig!

We can start with structure–that part of the design work seems well-cooked for now–, but add other element behaviors only if they seem ready and have customary usage in the wild. Some demo sites are very slow for browsers that lack fully optimized behaviors for advanced HTML5 features. If a particular HTML5 or CSS3 feature appeals just because it looks nifty, weigh its value against its impact to the user’s experience. This goes for anyone creating direct HTML5 content as well as for Web content generated from XML source formats like DocBook or DITA.

Summary

I am certain that I’ll need to revisit this discussion in a year to see if I still assess things the same way. But it is clear to me that browsers already make use of a great deal of these capabilities that beg to be put into use as appropriate!

Note that since HTML5 is intended to become Business As Usual on the Web, the “5” part of the name will eventually go away, and we’ll be talking about these as “latest HTML” features.

Already by popular request, it looks like I’ll be posting a follow-up demonstrating the use of multi-column layouts based on the HTML5 structural elements. Stay tuned!

3 Responses to What HTML5’s most-discussed benefits mean for DITA

I am exicited about HTML5 but Flash can do all these things html5 can do in a better way.Creating slideshow in HTML5! wow! what, flash did that 10 years ago! It is very easy to create a flash animation, for example a ball bouncing in flash professional in less than am minute. Javascript is a mess when compared to AS3.