The current HTML allows users to enter only plain text, leaving developers the pleasure of validating actual content against numbers, emails, dates or phone numbers. HTML5 comes with several new values for the attribute type of the INPUT element. Here are a few examples:
<input type="date" /> <input type="time" /> <input type="range" /> <input type="number" required /> <input type="email" />
What's the real effect of these values? The intended effect though not completely standardized yet is that browsers provide an ad hoc user interface so that users can comfortably enter a date, time or number. As of today, Opera 11 is the only browser that takes new values for the type attribute seriously. Opera 11 automatically pops up a calendar for dates and a slider for a range type. As Figure 1 shows, Opera provides also automatic validation for fields. The input field in figure is marked as an email field but it doesn't contain a valid email address and Opera complains! Finally, the required
attribute marks an input field as mandatory whereas the
placeholder attribute allows displaying a hint in a text box wherever possible. (You won't find a hint in a range input field that is rendered using a slider.)
Audio and Video
One of the biggest gains of HTML5 is saying farewell to external plugins such as Flash and Silverlight for playing audio and video. You have two new elements that point to a URL and play any content. The browser implementation of these tags is expected to provide a control bar for the user to pause and resume the playback.
The sore point of multimedia elements is the format (both file format and codecs) of audio and video files. The HTML5 won't make an official call, so deciding about the format to support will remain up to the vendors. From a developer's perspective this is not exactly great news as it represents a breaking point different browsers support different formats and you should detect the browser or provide multiple files for the browser to choose. Here's the syntax to indicate a selection of formats.
<video poster="init.png" controls> <source src="..." type="video/mp4" codecs="..." /> <source src="..." type="video/webm" codecs="..." /> </video>
Note that you use the
controls attribute to display the control bar and the
poster attribute to specify an image to use as a splash-screen until the media is ready to play.
Data Storage and Offline Working
We all know that Websites need an active Internet connection to work. Whether Ajax or browser-led, any requests the user generates by interacting with the site are to be delivered to some remote endpoint to obtain a response typically, a Web page or auxiliary resources like images, scripts and styles. All browsers have some caching mechanism specifically introduced to save a few HTTP requests by resolving static resources from the local computer. However, this mechanism has never been standardized and any browsers use it more as a form of optimization than as a way to enable users to work on the site while offline.
HTML5 comes with several separate specifications for Data Storage and Offline Applications. Altogether, these APIs provide a framework for developers to build Web applications that not only force the browser to cache resources according to a public manifest, but also enable the local code to save application data in a custom format according to application-specific rules. One could say that data storage is a very enhanced version of cookies, whereas offline working is a very enhanced version of the classic browser cache.
You access the local storage through the
localStorage property exposed by the browser's window object. This property offers a dictionary-based programming interface similar to that of cookies. There are methods to add and remove items, to count the number of items in the store, to get the value of a particular item and to empty the store. You use the manifest cache special resource, instead, to let the browser know about which resources to cache and which to always request to the network. You reference a manifest this way:
Note that the URL can be a dynamic page (for example, ASPX, PHP) and the resource must be typed as text/cache-manifest. The content of a manifest file is a plain list of resource names with a bit of syntax rules:
CACHE: default.html styles.css logo.png NETWORK: login.aspx /public/api FALLBACK: login.aspx nologin.png
The CACHE section indicates resources to always cache; the NETWORK section lists resources to always request from the server; the FALLBACK section indicates alternate resources to use when network is not available.
So is HTML5 ready for prime time? HTML5 is definitely receiving a very warm welcome and its features although not standardized yet are gradually finding support in recent browsers. Some flavors of HTML5 are available today in Opera, Chrome, Firefox, and Internet Explorer 9. They are, however, flavors. Browser incompatibilities do exist and will likely continue to exist at least until the specification is finalized around 2014. What should you do today?
As far as Web applications are concerned, either you exercise control over the browser or you provide a powerful fallback mechanism. Input elements can be coded as HTML5 and they will render gracefully on older browsers; semantic elements such as ARTICLE should be styled appropriately to render gracefully on older browsers.
You also need to provide fallback for media elements. In the end, it's not a mission-impossible task, but it is an extra amount of work that, as I see things, doesn't pay off currently. What's the point of serving HTML5 markup instead of plain old markup?
It's a totally different story if you intend to leverage companion features of HTML5 such as offline or data storage. But, again, what if the browser doesn't support HTML5 or, supports it partially? You have to code two versions of the site. A library like Modernizr helps in that it performs feature detection.
Dino Esposito is the author of several programming books, including the recent Programming Microsoft ASP.NET 4 from Microsoft Press.