HTML5 is coming, and it’s not just the next version of HTML.
HTML began as a lightweight mark-up language for linking documents on the web, with some rendering hints. As new versions have come along, support has been added for new kinds of content (images, video, interactive content). More recently, interest has grown in understanding documents and web applications on a deeper level. The most prominent example of this is the semantic web, which seeks to move from a “web of documents” to a “web of information”.
All previous versions of HTML make this an extremely challenging task, akin to trying to understand a philosophical text presented in terms of its typography.
HTML5 will change that. The designers of HTML5 have taken great care to separate semantic content (the information a document is intended to convey or represent) from the process of rendering (how a document should appear in a browser). Through this “separation of concerns”, HTML5 is equipped to revolutionize how we think of the web, how we work with it, and how we create new content. Our interest is in the potential for HTML5 to change how we specify, design, build, and analyze user interfaces – wherever they may appear: on the web, mobile devices, or desktop.
With consistent user experience as our guiding motivation, we survey the state of the art and practice of tool support for semantic reasoning about HTML5.
Galois was recently awarded a Phase II SBIR contract by the US Army to develop automated tools capable of checking a user interface against a set of UI Guidelines, such as the Apple Human Interface Guidelines,Usability.gov’s Web Design and Usability Guidelines, and the Associated Press Stylebook. One of the key challenges with evaluating user interfaces is understanding the interface description in the first place. Choosing a common description language to support is therefore critical to success. An ideal language would support the ability to add semantic meaning to the UI description (to assist with reasoning about semantic guidelines) as well as build a vibrant community of developers and users.
HTML5 is a natural fit on both of these counts. Support for microdata, microformats, and/or RDFa will extend the already rich set of semantic annotations in HTML5. The language also caters to one of the most prolific development communities around. Furthermore, HTML5 is on the cusp of flooding user interfaces on the web, on mobile, and on the desktop. In fact, it is mostly here already: all of the leading the browsers support many proposed aspects of HTML5. Although the specification is not finalized (at the time of this writing), it is clear that the future of the web is HTML5.
Web development tools cover a wide spectrum: editors, debugging consoles in browsers, headless test environments, lint tools, and other validators. When the W3C asked their community what they needed and wanted from web development tools, the results unsurprisingly included the whole spectrum of current tools. However, developers also wanted tools that could analyze their work for desirable but subjective properties, like ease of maintenance, forwards compatibility, and cross-platform compatibility.
HTML5 is more than just the next version of HTML. It opens up genuinely new possibilities, like realizing the semantic web. As HTML5’s use expands into new domains, developers will be interested in new kinds of analysis, tailored to their use-cases. For example, the design criteria for Windows 8 Metro-style applications will differ significantly from those used to target iPhone-based browsers—we can only guess what other platforms will arise in the next five to ten years.
What does this mean for the working web designer, developer, or content creator? What tools are available now that support HTML5 development? What tools do we need? We can begin to answer these questions by compiling a list of the primary tools available now for HTML5 development.
We begin with a look at what makes HTML5 so different from its predecessors. Then we will discuss why HTML5 has something to contribute to the world of user interface design1. We will continue with a brief survey of the current state of analysis tool support for HTML5, and will close with a discussion of where we see gaps.
Separation of Concerns
HTML5, when it is finalized, will be the fifth revision to the core language of the web. In our view, it is the most significant revision made to date, and not just because it will subsume (or make obsolete) XHTML 1 and all prior versions of HTML, while maintaining backwards compatibility (read more on the differences between HTML 4 and HTML5).
The designers of HTML5 have taken great care to separate the description of semantic content (i.e., what a given element of page is intended to convey to user, the action it is intended to perform, or the role it is intended to fulfill) from the process of rendering (such as how a browser should display a given element, or how that element should appear when printed).
For example, using HTML5’s video tag instead of embedding a Flash player, the consumer sees the video as played by his/her browser’s default player (the configuration of which is under the user’s control). The HTML5 tells the browser what the content is (and other information, like its URI); the browser decides how to display it2. Apart from empowering the user, this provides some measure of forwards-compatibility: video players are certain to continue to improve over time, and those in use today are by no means guaranteed to work correctly five years from now. The video tag – by not specifying a player, but merely the desired functionality – allows for renderers to change over time.
HTML5 for User Interfaces
This separation of concerns, the “what” from the “how”, is also a guiding principle of good GUI design (and good design in general). Keeping this principle in mind leads to cleaner design (not polluted with premature commitment to a particular low-level rendering), which has a myriad of benefits: easier maintenance, easier extension, and simplified design-level debugging, to name a few.
That this principle is exemplified in HTML5 is no accident: web-based applications are becoming increasingly indistinguishable from their desktop or mobile counterparts, and this trend will continue as browsers look more and more like complete operating systems3.
If we can describe enough of the intended user experience and look and feel in HTML5, then we have a hope of providing consistent and familiar user interfaces across platforms. When one of those platforms is a browser being used as a rendering engine, the distinction between “web-app” and “app” is no longer relevant. Indeed, Microsoft is saying as much with their—somewhat controversial—plan to grant HTML5 (with JavaScript) the status of a fully supported Windows 8 development language (for developing metro style applications, Microsoft’s desktop, mobile touchscreen, and Xbox application framework).
Survey of Existing Tools for HTML5
Editors and Debugging Aids
Many tools that work for any earlier version of HTML will work fine for HTML5: text-based editors, browser-based debugging aids, etc. Support for creating valid HTML5 documents may be found in several general-purpose integrated development environments (versions of Visual Studio, Eclipse, and NetBeans, to name but three). Adobe Dreamweaver also supports HTML5.
All of the popular browsers that support HTML5 have developer consoles (either built-in, or available as plug-ins), where a web developer can browse detailed error and warning messages (generally pertaining only to JavaScript), and even edit local copies of a page’s HTML, CSS, and JavaScript to test potential fixes. These can help find what we think of as surface bugs – such as having misspelled a link or having failed to initialize a JavaScript variable – but are less than helpful when it comes to finding design bugs (where bugs arise from an incorrect or ambiguous description of the intended behavior) or semantic bugs (where bugs might arise from a misunderstanding of the intended behavior, or from unintended behavior).
Validators
Validators check that a given document (usually HTML or XHTML) is well-formed according to some fixed schema or semi-formal specification. This is more than a simple syntactic validation, as a schema may impose structural constraints and some simple semantic constraints.
- HTML5 validator.nu: Validates a document against the current draft HTML5 specification.
- W3C’s Validator: Validates a document according to its stated DOCTYPE; if HTML, then it validates against the latest draft of the HTML5 specification. This service can also generate a corrected version of the document.
However, it appears the W3C validator is based on the tool from validator.nu. Thus, there is in essence only one standalone4 HTML5 validator readily available at the time of writing.
Static Analysis Tools
In general, a “static analysis tool” is any tool that provides feedback on a document’s static form. Any validator is also a static analysis tool, but we make the distinction here because, for the community at large, a validator performs a very specific analysis: checking conformance to a specification. We will use static analysis tool to refer to any tool that gives feedback about higher-level and often subjective properties of a document, such as “approved coding style”, “pleasant visual design”, or “conforming GUI”.
The most familiar static analysis tools in web development are lint-like tools. Intended to analyze only well-formed documents (i.e., that pass validation), lint tools highlight anything that experience has shown can lead to bugs, portability problems, and maintenance issues. HTML Lint, while a work in progress, is the first tool of its kind that supports (or even claims to support) HTML5. More are sure to follow, such as an updated version of HTML Tidy or TidyLib, perhaps.
Web accessibility addresses equal access to the web for all people, whatever their hearing, movement, sight, and cognitive ability. HTML5’s semantic separation is hoped to make this easier. The W3C is setting standards for accessibility and has a task force set to review the HTML5 specification for its impact on web accessibility, and to suggest changes.
This is a challenging task, as accessibility is a subjective property. WAVE (Web Accessibility Evaluation Tool) is an HTML5 analysis tool focused on accessibility. Interestingly, WAVE integrates accessibility feedback into the original web page, making the feedback itself much easier to absorb. Additionally, the tool is intended to aid humans in evaluating the accessibility of web content, not to proscribe a particular style. This is a sensible approach, given the subjective nature of accessibility, and it is a pattern we are likely to see repeated for other subjective properties (like “good user experience”, or “conforming GUI”).
Indeed, there seems to be a growing consensus in the community that validation is not sufficient for HTML5, that static analysis tools are going to be crucial. We concur.
What Does the Future Hold?
HTML5 opens up many possibilities and grants web designers and developers more freedom and powers than they have had before. However, with that expressiveness comes ample opportunity to shoot oneself in the foot. Tool support, particularly that which goes deeper than syntax and schema, will be needed. We can already see a need for tools that enforce properties more expressive than validator guidelines or linter rules. For example, many user interface guidelines exist in human-readable formats; these guidelines cannot all be checked automatically, but we believe many of them could.
This article also has not touched on the topics of JavaScript-enabled interfaces, template languages such as Microsoft’s Razor syntax, or dynamically generated content in general—more on those topics will be coming soon. For now, we hope this survey is valuable to you, and we welcome your feedback and suggestions to fill any gaps you see.
Web Designers and Developers!
- Did we miss any HTML5 tools that you use, love, know of, and/or developed? Or did we get something wrong? Please let us know!
- What is your use-case for HTML5? Is it supported by the tools you use?
- Where do you think you will need tool support for HTML5?
Footnotes
1 Much has already been written about the connection between HTML5 and the semantic web, so our focus here will be on a different but equally disruptive use of HTML5: specifying user interfaces.
2 More accurately, the browser decides how to render based on its own defaults and any designer-specified styling (through, e.g., CSS3).
3 One could argue that the trend is for the converse: that desktop applications are becoming more like mobile and web applications.
4 It might be argued that the WYSIWYG IDEs/editors effectively perform validation, by showing syntax errors where present.