The Future of the Web: HTML5

Robert Boedigheimer is talking on this and other topics at the DevWeek 2011 conference in March. Full details of all the 100+ sessions and workshops at DevWeek are available at www.devweek.com.

Let’s get this one cleared up in the first sentence, no you don’t have to wait until 2022 to start using HTML 5! The 2022 date is when HTML5 is supposed to become a “Proposed Recommendation” which means that everyone has agreed on the spec and there are 2 complete implementations. None of that really matters to web developers, what should matter to us is when our users’ browsers support a given feature we are interested in utilizing. There are also clever approaches that allow even our favourite older browsers (think IE 6) to use some of the new features.

Approach

The W3C was working on XHTML 2.0, pursuing a clean break from existing markup to create a new language for the web, when a rift formed with a group that felt strongly that it was a mistake to break compatibility with so many web sites. That group split off and formed the WHATWG (Web Hypertext Application Technology Working Group) to pursue enhancements to HTML that provided better support for web applications while remaining backward compatible. The W3C eventually abandoned pursuing XHTML 2.0 and the two groups are once again working together on HTML5. The two main design principles were “Pave the Cowpaths” (standardize already accepted implementations) and “Don’t Reinvent the Wheel” (don’t create new techniques where ones already exist).

Simplifications

One of the first goals was to simplify where possible. Why is it that we always have to specify “text/javaScript” on our <script> tags when it is really the only universally available client language? Why do we still have complicated <doctypes>? These and several other areas were simplified for HTML5. It doesn’t really add any new capabilities, it just makes life easier.

Conforming and Non-conforming

HTML5 attempted to keep as much compatibility as possible with existing implementations, but there have been minor modifications to some elements. There are elements and attributes that should no longer be used. Most of these should require only minor modifications. A page that follows all of the new rules is said to be “conforming”, while those that don’t are called “non-conforming”.

Feature Detection

In the bad old days, web sites would employ user agent “sniffing” by looking at the user agent string sent to the server in an HTTP header and lookup (or just know) what that given agent supported. The problem with that technique is that there are so many more user agents these days, and it is hard to keep up to date with the latest features available to each agent. A much more effective technique is to check the user agent to see if it supports a given feature. There are multiple techniques for determining if a feature is supported, the easiest is to use Modernizr. Modernizr is a JavaScript library that does the feature detection and provides either CSS classes or a JavaScript API to check if the feature is supported. The library does not add support for a given feature, it simply indicates if the feature is available in a given user agent.

HTML5 Shiv

What exactly happens in a browser that doesn’t support the new HTML5 features? Most browsers just ignore the tags but show styles, etc. IE will not apply any styles and does not update the DOM properly. An elegant solution was provided with the HTML5 shiv which defines the new elements so IE will allow them to be styled and accessed from the DOM. This does not mean that IE will play a <video> or allow drawing with <canvas>, but CSS styles can be applied and elements can be accessed via JavaScript.

New Input Attributes and Elements

One of the exciting areas in HTML5 is the addition of new attributes to the <input> tag. The new “placeholder” attribute sets up what has often been called a “watermark” in an input field. It faintly shows text in a textbox, for instance that can help indicate what should be entered, but as the field gets focus the text disappears. Another useful attribute is the “autofocus” which places the initial focus into a given field. This is much better than the traditional use of JavaScript since browsers in the future may allow it to be turned off, and it won’t suddenly jump to another field when JavaScript finally kicks in. There are also a whole new series of input types for email, telephone numbers, URLs, dates, colors, etc. As browsers add support for these new types, they can provide better validation and improved user experiences.

New Structure Elements

Web sites today are often a bunch of <div> tags, which tell agents like browsers and search engines very little information about the semantic meaning of areas of the page. After analyzing a large number of web sites, it was obvious that creating new elements like <header>, <nav>, and <footer> could add value to nearly every page on the Internet. These tags provide much more information about a portion of the page, so accessibility tools can see the

Canvas

The new <canvas> tag provides a JavaScript drawing API. It currently provides support for 2D rectangular drawing areas. It can be used to write text, circles, squares, etc. It has also been used to create games that previously required more advanced plugins like Flash or Silverlight. There is a JavaScript library called [ExplorerCanvas] (http://code.google.com/p/explorercanvas/) that adds support for the canvas tag in IE.

Media

Two new media related elements <audio> and <video> (which provide what you would expect) may someday reduce reliance on plugins. Both have support for listing multiple video sources, which the browser can choose the first one it knows how to play. It also has support for a fallback mechanism to allow use of Flash or other techniques if the browser can’t use any of the sources. The new elements have standard controls so that users will become accustomed to a particular look and feel which will make it easier for them to use video across multiple web sites.

Web Storage and Offline Web Applications

Cookies have long been the mechanism that web sites used to store some local data on a user’s machine. The problem is that they are very limited in size and get transmitted with all requests to the given web site. HTML5 provides local storage up to 5 MB options for both a browser session and long term. The storage is a set of key/value string pairs. One area where support for this is critical is the new Offline Web Applications support. This provides the ability for web sites to run locally on a user’s machine even when they are not connected to the Internet. For some scenarios, this can provide for a functional application that uses local storage, and synchs up with the server when the user connects to the Internet.

JavaScript API

One of the biggest problems with JavaScript and browsers has been the lack of a standardized API that works across all browsers. jQuery and other JavaScript libraries have done a great job of lessening this problem, but now HTML5 is defining the API so that in the future there will be better consistency by default. The new API also supports features like drag and drop that promise to help bridge the gap between web and desktop applications.

Conclusion

Do you want to learn more? I will be giving a talk called “The Future of the Web: HTML5” at DevWeek 2011 which will go into much more detail including lots of examples. Don’t wait until 2012 or 2022 to start using HTML5, many browsers already have great support for individual features that you can start using today!

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” - Rick Osborne