“HTML5: If You Bang Your Head Against The Keyboard You’ll Create a Valid Document!”
Posted by Brian Kelly (UK Web Focus) on 10 December 2010
“HTML5 / CSS3 / JS – a world of new possibilities”
I recently attended the 18th Bathcamp event entitled “Faster, cheaper, better!“. For me the highlight of the evening was a talk by Elliott Kember (@elliottkember) on “HTML5 / CSS3 / JS – a world of new possibilities“.
The Elliottkember.com Web site describes Elliot as:
a freelance web developer based in Bath, England
who builds and maintains high-traffic, powerful web apps,
resorts to using 32pt Georgia – sometimes in italic and printer’s primaries,
has 4978 followers on Twitter, speaks at conferences,
and wants to develop your idea into an application.
Elliott gave a fascinating run through some of the new presentational aspects of HTML5 and CSSS, appropriately using a HTML5 document to give the presentation. His slides are available at http://riothtml5slides.heroku.com/ and are well worth viewing. Note that to progress through the slides you should use the forward and back arrows – and not that Elliott was experimenting with some of the innovative aspects of HTML5 and CSS3 so the presentation might not work on all browsers.
In this post I’ll not comment on the HTML5 features which Elliott described. Rather than looking at the additional features I’ll consider the implications of the ways in which the HTML5 specification is being simplified.
Elliot introduced the changes to HTML5′s by pointing out its simplicity. For example a HTML 4 document required the following Doctype definition:
<!--DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">-->
whereas HTML5 simply requires:
The following illustrates a valid HTML5 document:
<!--DOCTYPE html> Small HTML 5 Hello world -->
As can be seen there is no requirement to include the <head> and <body> elements which are needed in order for a HTML 4 document to be valid (although HTML 4 documents which do not include these mandatory elements will be rendered correctly by Web browsers.
What about IE?
Over the years developments to HTML standards have always given rise to the question “What about legacy browsers?“. Often the answer has been “The benefits of the new standard will be self-evident and provide sufficient motivation for organisations to deploy more modern browsers“. Whether the benefits of the developments from, say, HTML 3.2 to HTML 4 and HTML 4 to XHTML 1 have provided sufficient motivation for organisations to invest time and effort in upgrading their browers is, however, questionable – I know I have been to institutions which are still providing very dated versions of browsers on their public PCs. And whether the HTML technology previews which tend to be demonstrated when a new version of HTML is released will be typical of the mainstream uses may also be questioned. So there is still a question about the deployment of services based on HTML5 in an environment of flawed browsers, which includes Internet Explorer; it should also be noted that other browsers may also have limited support for new HTML5 (and CSS 3) features.
Elliott suggests that a solution to the “What about IE?” question may be provided by a HTML5 ‘shim’. A shim (which is also sometimes referred to as a ‘shiv’) is described in Wikipedia as “a small library which transparently intercepts an API, changes the parameters passed, handles the operation itself, or redirects the operation elsewhere“.
Remy Sharp has developed what he calls the HTML5 shiv, which consists of the following three lines:
<mce:script // -->
This code provides a mechanism for IE to recognose new elements, such as, as Elliott uses in his presentation, <slide>
Use it Now?
Should you start using HTML5 now? Back in July in his plenary talk on “HTML5 (and friends): The future of web technologies – today” given at the IWMW 2010 event Patrick Lauke suggested that for new Web development work it would be appropriate to consider using HTML5.
Elliott was in agreement, with his slides making the point that:
All decent browsers support enough of this stuff to make it worth using.
What this means is that you can start to make use of the simple HTML5 declaration but rather than use every HTML5 feature that is documented in the specification you should check the level of support for various features using, for example the Periodic Table of HTML5 Elements and the HTML5 Test web site and Wikipedia’s Comparison of layout engines (HTML5) as well as running standard usability checks on an appropriate range of browsers and platforms.
What About Validity of HTML5?
Following Elliott’s talk there was a question about the validity of HTML5 documents. Elliott responding with a very graphic depiction of the much more liberal (if one dare uses that word!) approach to validity: “If you bang your head against the keyboard you’ll probably create a valid HTML5 document!“.
Such an approach is based on observing how few Web resources actually conform with existing HTML specifications. In many cases browser rendering is being used as an acceptable test for conformity – if a Web page is displayed and is usable in popular Web browsers then it is good enough seems to be the situation today. ”After all” asked Elliott “how many people validate their Web pages today?” The small numbers of hands which were raised (including myself and Cameron Neylon) perhaps supported this view and when the follow-up question “Who bothers about using closing tags on <br> elements in XHTML documents these days?” was asked I think mine was the only hand which was raised.
The evidence clearly demonstrates that strict HTML validity, which was formally required in XHTML, has been rejected in the Web environment. In future, it would seem, there won’t be a need to bother about escaping &s and closing empty tags, although if Web authors wish to continue with such practices they can do so.
What About Complex Documents?
Such simplicity seemed to be welcomed by many who attended the Bathcamp meeting. But myself and Cameron Neylon, an open science researcher based at the Science and Technology Facilities Council, still had some concerns. What will the implications be if a HTML resource is being used not just for display and user interaction, but as a container for structured information? How will automated tools process embedded information provided as RDFa or microdata if the look-and-feel and usability of a resource is the main mechanism for validation of the internal consistency of a resource?
There are dangers that endorsing current lax approaches to HTML validity can hinder the development of more sophisticated uses of HTML, especially in the research community. We are currently seeing researchers arguing that the main document format for use in scientific and research papers should move away from PDF to a more open and reusable format. HTML5 has been suggested as a possible solution? But will this require more rigourous use of the HTML5 specification? And if the market place chooses to deploy tools which fail to implement such approaches, will this act as a barrier to deployment of HTML5 as a rich and interoperable format for the community?