Last month, the WHATWG (Web Hypertext Application Technology Working Group) announced the ‘last call’ for changes to the specification for the next evolution of HTML, HTML 5.
I’ve been watching the development of the new specification with interest because it could result in a much more usable markup language for web developers. The best bit about the new specification is that instead of just trying to patch up flaws in its predecessors, the specification is keeping the good bits and ditching the old bits nobody cares about whilst formalising the concept of web application frameworks using established APIs (as opposed to vendor specific).
The problem with plugins
Although CSS support has gradually become more uniform across browsers, creating designs that break away from the rectangular box mould is challenging – surprising when you consider the maturity of the Internet technologies that drive the sites we all use.
Most of the more-interesting parts of the Internet are dependant upon the client browser using plugin technologies to achieve a greater degree of user engagement. Vendors have made the client plugins free to download and install but that doesn’t change the fact that propriertary technologies are required to achieve what isn’t specified within existing markup standards. Of course, though the vendors of the more successful and pervasive plugins provide the client plugins for free, they charge a considerable amount for the authoring tools to create content for the plugins.
Farewell SGML
One of the first things that caught my attention about the new specification was the decoupling of HTML 5 from its root language; SGML. This makes sense when you consider that browsers don’t use an SGML parser to render web-pages. It’s only validators that do that – and even then, not all of them do.
HTML5 will (apparently) require that documents are served as either text/html or application/xml but not both. This does make sense when you consider how different the structure of a HTML document is when compared to a well-formed XML document. Either way, one think I won’t miss is the DOCTYPE line at the start of each web document.
The text/html model will be preferable to many, especially seeing that it doen’t force the strict well-formedness rules of XHTML 1.0 upon the structure.
Javascript
Many websites use Javascript to dynamically generate web-content. HTML 5 introduces some stricter rules as to how this should function. Two that particularly caught my eye were:
- If Javascript generates HTML content that includes elements, the closing tags for those elements must be escaped. This is because the data for the element starts immediately after the opening tag and ends at the first closing tag that is encountered. I’ve tried to show this in the code below – the closing tag for the bold element has been escaped so that the closing tag for the script element is processed first.
<script type=”text/javascript”>
document.write(”<b>This is bold text<\/b>”);
</script>
-
When writing event code for HTML elements, figuring out how to nest quotes within quotes was a nightmare. Now coders will be required to use HTML entity codes instead. This means that instead of this :
<input type=”button” onclick=”alert(’Hello World’);” />
it will be :
<input type=”button” onclick=”alert("Hello World");” />
Support for multi-lingual indexing
There will be support for linking translations of web-pages by using the link element and a language specifier – presumably this will enable the browser to display the page appropriate for the user rather than pages having to have specific anchor links to different pages.
Is that it?
This post barely even scrapes the surface of the new HTML 5 specification.
There are some very interesting multimedia extensions that will permit the embedding of video and sound within pages without additional plugins and the humble HTML tables will be receiving a fair amount of attention too.
The best part of the new specification is that some of it has already been implemented in newer browsers. Internet Explorer 8 and Firefox 3.5 have both introduced support for various parts of the new draft.
Whilst it might be fun to play with the shiny new toys, unless you know the majority of your site’s users are going to be using a supporting browser, HTML 5 probably isn’t ready for the masses yet.