“Standards are as interesting as a Russian Truck,” said Ken Olsen, president and CEO of Digital Equipment Corporation, at that time the second largest computer system company in the world.
It was a fairly strange statement to come from a person whose company had helped develop more computer standards than almost any other, and the press had a field day with that quote. If he said it today, Ken might be thought to be addressing HTML5, the long-awaited standard of what has become the most important publishing mechanism on the face of the earth…the web.
What Are We Really Talking About?
For those people that are not web designers and architects, there are several very important parts of the data that the average end user thinks of as “HTML.”
The first part is HTML itself, which is exactly what its name implies, a Hyper-Text Markup Language. HTML uses meta-data (in effect words that define words) to define the layout of words on a page and how to intermix URLs and other descriptive meta-data into the glob of text data. HTML typically defines “headers,” “paragraphs,” “highlighted areas” (notice I refrained from saying “bold” text) and other textually oriented things that have to do with the structure of a web page.
The second layer that some people have heard about is “Cascading Style Sheets” (CSS). CSS provides the “style” of how the page should look, what colors to use, the size of the borders, positioning on the page of the blocks of data, and so forth. CSS is the “form” to the “function,” the format of the data.
The third “layer” that you hear about is JavaScript. This typically provides the “dynamic” part of the page on the browser side, often allowing animation of the page, or allowing simple editing of input data.
To round out the technology pool, on the web server side of the equation is the web server, that can generate HTML with the CSS commands and Javascript embedded inline and/or use PHP on the server side to generate this stream of data and metadata on the fly. All of this, of course, has to be orchestrated by the designer of the web site.
The Non-History of HTML5
The path toward HTML5 has been long and arduous. The last full attempt at the standard was done in 1998, and since that time there have been several “false starts.” Likewise there have been some disagreements about whether HTLM5 should be “media centric” (i.e. used to “simply” display text, photographs, videos and other “media” on a browser screen) or should HTML5 be “application centric” (allowing applications to be written that would run in the browser, acting as a front end for client/server applications).
Likewise there were discussions about how strict the HTML parsers should be and whether they should lenient if the syntax error was minor. Most browsers have a “quirks mode” that is engaged when they can not fully parse the code that is sent to them. Unfortunately since these “quirks modes” vary from browser to browser, they often cause unpredictable things for the end user to see and “quirks modes” often make it harder to code web pages for reliable rendering.
All of this delay was causing problems because the web was demanding ever more functionality and at a faster pace than had been anticipated in the early years of the Web. This functionality was being provided by proprietary extensions that were not available for every browser, or on every platform, and web pages were not being rendered properly without those extensions.
People coding web pages had no real idea if their coding would actually be visible to any number of web browsers, because they did not know if these proprietary extensions were going to be present. And the cost of generating web pages was increasing as more and more web browsers were being implemented, causing testing costs to skyrocket.
Likewise, people implementing new browsers had no useful standard that told them when they might have reached “V1.0” status.
The good news is that at this point many browser developers knew the types of functionality that might be needed in the new standard, and many examples of the functionality already existed in one browser or another so people developing that standard could see it work. A lot like the POSIX standard, some of HTML5 is simply documenting how to do functionality in a standard way rather than reinventing a new functionality from the ground up. Likewise, as parts of the new standard have been defined and solidified, various browser developers have actually implemented parts of the new standard already. Combined with careful attention to backwards-compatibility, it means that HTML5 may be a graceful migration rather than a jolting step-function for the web.
Features from the Top Down (or is it bottom up?)
This web article could not hope to compete with the actual specification to list everything new and every nuance of those new features, but will look at a few of the features and how those features will help web page designers.
It should also be pointed out that neither the working group that is generating a lot of the input into the standard (www.whatwg.org) nor the W3C (www.w3.org), which actually “owns” the standard, have had a final vote on the full standard, so some of these features listed here may or not make it into the formal standard.
Stay tuned.
Structure, always structure
New to HTML5 are structural tags like <section>, <header>, <article>, <footer>, <nav> and <aside>.
Now these sound like common sense, since many word processors allow you to define a “header” and a “footer” section in your document, and a “section” of a document can be made up of many articles with headers and footers, so you can (in effect) embed whole nested documents into your page. <nav> allows you to set up a navigation area with a set of links, like a menu and <aside> allows you to segregate information that might appear in a side-bar like area beside your main text.
Some people will say, “I could do the same with “div and id” and while that is true, it is felt that actually calling out what the tag is about will make coding clearer to read and therefore better able to be modified at a later time. As with “divs,” “id” is also applicable to these tags. Of course the actual placement would also be controlled by your style sheets.
Off-line data storage
Lending a hand to the “application centric” part of the web, the addition of off-line data storage will allow applications to have mechanism for storing persistent data. Cookies have always given a limited amount of storage, but not really enough for things like off-line reading of email, or storing of applications.
The interface will allow web application designers to specify in a “manifest” the files that the web browser needs to store on the local system so the application could continue to operate offline. For example, if the application is strictly a web application written in HTML with a css file and a JavaScript file, these three files could be extracted from the server and stored on the client by the browser so the application could continue to run “off-line.”
Canvas
A <canvas> is a border-less rectangular element that has attributes of width and height but no content at its creation. There may be several of these elements on a page, and you can assign each one of them an “id” attribute so you can address them. The canvases can be drawn upon by using JavaScript, through an API and there are a series of different commands for drawing different shapes, gradients, text, colors, patterns, scaling functions and even putting images onto the canvas.
The authors of the HTML5 standard envision canvases for creating dynamic displays on the web such as graphs, drawings, or other “visual images.” They caution people not to use canvases when other, more appropriate techniques would apply. They particularly caution against using canvases to draw elements that are “graphically intense” and might be more easily rendered or animated using images.
Input elements
There are also a series of input elements that will help interactive document or application developers get input more easily. URLs, email addresses, date-and-time, radio boxes, file names and other commonly input data will have mechanisms to check for proper syntax and return this data to the program.
Drag and drop
HTML5 offers a mechanism for setting up “Drag and Drop.” It defines what the different actions of drag and drop are supposed to do, such as “selecting,” “dragging” and “dropping,” but not what exact mechanisms are needed by the browser to facilitate these actions, nor exactly what is being dragged or dropped. So the specification talks in terms of “dragenter,” “dragstart,” “drop,” “dropeffect,” and “dragend” (among others) and allows the browser implementer to determine exactly how to show this action. This would allow a mouse-less browser to have selection done by arrow keys with highlighting, and dropping by navigating to a directory and hitting another key.
Embed
Plug-ins are a way of life with browsers. They allow third parties to extend browser capabilities. To allow web page creators the same ability, the “embed” element allows the creator of the web page to embed some non-HTML functionality or interactive content into their document.
Sandboxing
To be considered along with “embed” is the concept of “sandboxing,” allowing a limited set of capabilities for the embedded application, in case the application is not “well behaved.” Perhaps the sandboxed application will not be allowed to access cookies, or execute scripting. The standard calls for the browser to warn the user if the embedded item is violating the sandboxing constraints, but does not specifically call out what the browser is supposed to handle the violation.
Progress
The progress element allows a web page designer to easily give feedback to the viewer when an indeterminately long action might take place.
Video and Audio
Probably one of the most anticipated and exciting things about HTML5 is the addition of the Video and Audio APIs and meta controls. Now through a relatively simple set of HTML coding APIs, a web page designer can display a video on the screen and even supply browser-consistent controls to be applied to the videos. That is the good news.
The bad news is that there is not a common video codec across all of the browsers. Freely distributed browsers are limited to using freely distributable codecs such as Theora (for video) or Vorbis (for audio). Browsers distributed by a licensed, revenue-generating code base or hardware that is associated strongly with that code base can afford to pay the royalty for royalty-bearing codecs, and some of them have chosen to support H.264, a codec that bears royalties for both the code itself and for the encoded streams when the streams are sold commercially.
This split of codecs, of course, creates a small problem. People that want to ensure their videos are being displayed by every browser will have to encode them in two different code streams, taking up additional storage of the videos. FOSS end users may have to get encoders and decoders from places that have paid the royalty for them. And web-masters will have to have mechanisms of determining how many gigabytes of data will be downloaded from the royalty-bearing H.264 and MP4 data streams (and whether they were “commercial use” or not) or from the non-royalty bearing Theora/Vorbis data stream.
As of this writing the split seems to be:
Theora, Vorbis and Ogg (the container): Firefox, Opera and Chrome
H.264 + ACC + MP4: Safari, iPhone, Android and Chrome
Chrome is supporting all of the recommended video codecs.
Firefox and Opera could develop an appropriate interface for a plug-in that would allow for a royalty-bearing codec to be loaded into their browser and we will hope that a Theora/Vorbis freely distributable plug-in might be developed for Safari, iPhone (assuming that Apple allows it to be installed on their products) and Android.
MathML and SVG
The current W3C document states that Mathematical Markup Language (MathML) and Scalable Vector Graphics Language (SVG) elements may be used inside of HTML5, for example:
<svg> <circle r=”150″ cx=”150″ cy=”150″ fill=”blue”/> </svg>
would draw a blue circle. Thus both complex mathematical statements and two-dimensional vector graphics should be easier for web page designers to present on their web pages.
Notably absent
There are some absent elements in HTML5, things which the various committees felt were either obsolete or destructive. One of the biggest is the concept of “frames,” which was removed because it affected usability and accessibility “in a negative way.” Likewise, a large number of the “style” attributes (“background,” “border,” “width,” etc.) that were in HTML4 have been removed, allowing CSS to provide that style information.
Validation
Validation of your HTML5 code will help to ensure that the code will be able to be run by any HTML5 compliant web browser. The validated code still might not render the way you would hope but probably “something” will show up on the screen. And by validating your code, you will hopefully avoid any obvious issues that too little coffee and too long hours have created.
Three issues about validators:
• The standard is still changing. Therefore what is “valid” today may not be “valid” tomorrow.
• The validators are still changing. While the creators of the validators are doing their best, as with any standard and “test suite,” as the standards are improved and more thoroughly specified, the people writing the validators will improve and tighten the tests.
• Since the HTML5 standard was written to be backwards compatible from an HTML perspective, just because an element has not been specified in the HTLM5 specification at this point does not mean it has been deprecated.
Yet I disagree with the people who say, “what is the sense of validating?” Eventually the specification will move closer to completeness. Eventually the validators will tighten their tests. Having pages that have passed the validation tests for HTML5 will mean that they will have longer life than pages that have not passed the tests.
There are several validators of HTML5 available. One that is very good is at this web site: http://html5.validator.nu/ Please take the time to read the “About this service” at the bottom of the page. Note that this is a validator for HTML, and not CSS or Javascript.
Conclusion
“Standards are as interesting as a Russian Truck” was the quote from Ken Olsen that started this piece. It was at the opening of the Open Software Foundation, which eventually developed and published the three-part OSF/1 standard for Unix:
• a written standard
• a set of test suites
• a sample implementation
And, Ken was asked to clarify what he meant. He told the audience that as an engineer he personally hated the tiny detail work and incessant arguing and compromising that goes along with creating standards and working in a standards body. “It is a personal thing,” he said. Once the standard was created though, as an engineer, it was his job to create the best possible implementation of it, one that was compliant, stable, secure, fast and small. That, to Ken Olsen, was the “interesting part.” But without standards, chaos would ensue.
HTML5 will standardize a lot of things that have been done “ad hoc” over the past ten years, and as such will build a solid base for the web to build on.
References
Here are some useful web resources for HTML5:
World Wide Web Consortium (W3C)
Working Draft of HTML5 Differences From HTML4
Working Draft of the HTML5 specification
WhatWorkngGroup
Working Draft of the HTML5 specification
A sometimes irreverent and often humorous work on HTML5 by Mark Pilgrim can be found here:
http://diveintohtml5.org/ Mark has excellent descriptions of some of the highpoints of HTML5 and examples of its use. This is a work “in progress” and eventually will be published by O’Reilly as a hard-copy book, but is available online for free.
