At the Forge

One of the amazing things about the Web always has been the relative ease with which you can create a site. All you have to do is learn a few HTML tags, create a file that uses those tags, and voilà, you have a one-page site. Learn another tag or two, and you now can create multipage sites that contain images, links to other pages and all sorts of other goodies. Really, it doesn't take more than a few hours to learn the basics of HTML.

The problem is that this shallow learning curve has long masked the fact that HTML's vocabulary hasn't kept up with the times. Yes, it's very easy to create a site, but when you want to start styling the site, things become a bit more complex. And, I don't mean they become complex because CSS is hard for many people to understand (which it is). Rather, things become complex because styles often are attached to span and div tags, which means that pages end up containing many span and div tags, each with its own ID and/or class, so that you can style each thing just right.

Now, there's nothing technically wrong with having dozens of div tags on a page of HTML. But, at a time when Tim Berners-Lee and others are talking about the “semantic Web”, and a growing number of computers (rather than people) are trying to retrieve and parse documents on the Web, it seems odd to stick with such a limited vocabulary.

While I'm complaining, it's hard to believe that HTML forms barely have changed since I started using them in 1993. Given the number of sites that ask you to enter e-mail addresses or dates, you would think that HTML forms would include special provisions for these types of inputs, rather than force people to use text fields for each one.

In fact, there are a whole bunch of problems with HTML in its current form, and with many of the CSS selectors that allow you to style it nicely. HTML has been a part of my life for so long, some of those problems didn't even occur to me until I started to think about them in greater depth. Fortunately for the Web though, I'm not the one in charge of such thinking. After a number of fits and starts, the HTML5 specification (and a few other related specifications, such as CSS3), which includes no small number of improvements, is beginning to gain popularity.

The good news is that HTML5 (and friends) has a great deal to offer Web developers. Indeed, I've already switched all of my new development to use HTML5, and I'm hoping to back-port applications where possible. However, HTML5 is a catchall phrase for a huge number of different tags, functions and CSS selectors—and, each browser manufacturer is implementing these piecemeal, with no guarantee of 100% compliance in the near future.

This puts Web developers in the unenviable position of being able to enjoy a great deal of new functionality, but also constantly having to check to see whether the user's browser can take advantage of that functionality. I find this to be a bit ironic. For years, many of us have touted Web and server-side applications as a way of getting around the headaches associated with the compatibility issues that plague desktop applications. Although browser compatibility always has been an issue of sorts, the problems we've seen to date pale in comparison with our current issues, in part because the HTML5 elements are more advanced than we've seen before. (The closest equivalent would be the browsers that lacked support for forms, back in the early days of the Web.) At the same time, JavaScript is now mature enough to provide us with a way to test for the presence of these features, either on our own or by using a third-party library.

This month, I'm looking at some of the promise HTML5 brings to the table, with a particular emphasis on some of the syntax, elements and attributes that are coming into play. I also explain how to use Modernizr, an open-source JavaScript library that automates testing for various HTML5 features, so you can use an alternative.

I should note one subject that has been at the center of much public discussion of HTML5 that has to do with video and audio formats. These topics certainly are important and of interest, but they also are complicated, in terms of browser compatibility and licensing issues. It's true that HTML5 simplifies the use of video in many ways, but it's still a complex issue with no truly simple resolution. If you're interested in this subject, I suggest you look at one or more of the books mentioned in the Resources section of this article.

If you're like me, the first thing you do when you create the first standards-compliant HTML (or XHTML) page on a new site is copy the doctype from an existing site. The doctype not only provides hints to the user's browser, indicating what it can and should expect, but it also provides a standard against which you can check the validity of your HTML. If you fail to provide a doctype, not only are you failing to hitch your wagon to any standard, but you're also telling Microsoft's browsers that they should operate in “quirks mode”, which explicitly ignores standards and will wreak havoc on your HTML and CSS.

Modern HTML declarations are long-winded and easy to get wrong, so I never type them myself, but rather copy them, either from an existing project or from someone else on the Web. Fortunately, HTML5 simplifies this enormously. Generally, you just have to put the following at the top of the page:

<!DOCTYPE html>

After the doctype, the HTML document looks and works much like you might expect. For example, a document has a <head> section, typically containing the document title, links to stylesheets, metatags and imported JavaScript libraries. Perhaps the most common metatag you will use is the one determining the character encoding; nowadays, just about everyone should use UTF-8, which you can specify as:

<meta charset="utf-8" />

Following the <head> section is the <body> section, which contains the page's actual content. Tags continue to work as they did before, but the rules are somewhat relaxed. For example, you no longer need to quote attribute values that lack whitespace (although I think it's a good idea to do so), and you can omit the self-closing trailing slash on such tags as <img>.

If you are tired of using <div> to divide up your page, and use an “id” attribute of “header”, “footer” or “sidebar”, cheer up, you're not alone. Google apparently did some statistical analysis of Web pages and determined that a huge number of sites use divs to set up their headers and footers, among other things. In order to make HTML5 more semantically expressive, the specification includes a number of new sectional tags, such as <section>, <article>, <header> and <footer>. You even can indicate that a particular set of links are for navigation, such as a menu bar, by putting them inside a <nav> tag. Note that these new tags don't change anything other than the semantics, as well as the ability to style them by tag, rather than by ID. Although this won't necessarily change the technical layout of pages, it will make them easier to read and understand, and it also will make it easier for search engines to parse and deal with documents without having to look at IDs and classes, which are arbitrary in any event.

If you ever have created a Web application, you undoubtedly have needed to ask people to enter their e-mail addresses or telephone numbers. In both cases, you needed to use a text field, and then presumably check (using JavaScript, a server-side program or both) to ensure that the e-mail addresses were valid, or that the phone numbers contained only valid characters. Fortunately for users and developers alike, HTML5 specifies a number of new types of input and form elements, from fields specifically meant for telephone numbers and e-mail addresses, to color pickers and sliders.

Before HTML5, if you wanted someone to enter a URL, you would use a simple text field:

<input type="text" name="homepage" />

In HTML5, you can use the special url input type:

<input type="url" name="homepage" />

Many Web sites pre-populate text fields with a hint or a description of what should be entered there (for example, “Enter a search term here”), which disappears when you first click in the field. HTML5 automates this, allowing you to provide “placeholder” text:

<input type="text" name="search" placeholder="Search here" />

You even can restrict the values you will allow in various fields, using regular expressions, by setting the “pattern” attribute. You also can ask users to input dates and times without having to specify six separate inputs:

<input type="datetime" name="datetime" />

These form elements have more than just semantic value. The browser itself then can monitor the elements to ensure that submitted data is valid. This doesn't remove the need for server-side validation and checking, but it does greatly simplify things.

All of this sounds wonderful and will make HTML forms more useful and valid than they have been to date. But, and you knew there had to be a catch, support for these HTML form elements is very spotty and inconsistent across browsers. Opera seems to be the leader in supporting them, with Apple's iPhone/iPad following, and the Safari browser coming afterward. Support for such terms in Firefox is nearly nonexistent. Now, it's true that when a browser is asked to render an input tag it doesn't recognize, it produces a text field, which generally is fine. And, it's possible to get around the problematic cases, such as date- and color-pickers, with JavaScript. But, I'm still frustrated that it will be some time before we will see it implemented.

Another killer HTML5 feature, the “canvas”, has been in the works for several years already. It provides a 2-D drawing area that you can control (writing and reading) using JavaScript. The canvas makes it easy to create graphs, charts and even simple drawing programs, with functions that support the creation of various shapes, lines, images and even gradient fills.

I tend to be a text-oriented kind of guy who relies on designers to do much of the graphics in Web sites. Nevertheless, it's clear to me that the canvas, which is supported by recent versions of Safari and Firefox and will be included in Internet Explorer 9, will open up many possibilities—not only for displaying graphs and charts, but also for drawing under and over text and graphics, and allowing for new, mouse-based interactions and information display within the browser.

One of my favorite new features in HTML5 is geolocation. To date, geolocation has been a very iffy business, often depending on IP addresses. This often produces results that aren't quite accurate—for example, most IP-based geolocation libraries indicate that my house is in the city of Lod, about a 20-minute drive from my city of Modi'in. Now, that's not too far off if you realize how large the world is, but it's not quite good enough for geolocated applications, from supermarket finders to friend locators.

Although HTML5 doesn't officially include a geolocation standard, it's being developed and released along with HTML5, so I feel comfortable lumping it together with the standard. (And I'm not the first one to do so.) By providing functionality in the browser, it's possible for a JavaScript program to grab your current location:

navigator.geolocation.getCurrentPosition(function(position) {
    alert("longitude = " + position.coords.longitude + ", 
    ↪latitude = " + position.coords.latitude);
   });

There are a variety of additional pieces of functionality, including some that will help you track speed and movement, for applications that help with navigation. And, I can't tell you why, but the geolocation in HTML5 browsers consistently has been more accurate than the simple IP-address locators. That alone is good news for people planning to rely on such functionality for application development.

Now, if the general availability of geolocation information to any Web application gives you goosebumps, rest assured that the good folks creating these standards have tried to ensure your privacy. When the geolocation function is invoked, and before it returns any results, the user is presented with a dialog box in the browser, asking if it's okay to share location information. This message specifically indicates the site that is asking for the data, blocking its execution until the user responds.

In case you're wondering, the fact that you can get location information in JavaScript doesn't mean you're forced to write all your software in the client using JavaScript. You always can take the geolocation information and send it to the server using an Ajax call.

Geolocation depends on being able to rely on this functionality existing in the browser. At the time of this writing, there is full support in a variety of browsers, but not in Internet Explorer or Opera. On such systems, you might need to contact the server to perform an IP-based geolocation server call, with all of the issues that raises.

That said, I'm rather excited about the introduction of geolocation in future browsers, and I'm looking forward to see what applications crop up as a result.

As I indicated earlier, it's nice to know that HTML5 is being rolled out in stages, and that we don't need to wait for a complete implementation to be ready, which might take a number of years. However, it also means that each browser supports a slightly different subset of the HTML5 standard, which spells trouble for Web developers aiming to address users with a uniform platform.

Fortunately, there are ways to check with the current browser to see whether it supports each of the features offered by HTML5. However, you probably want to be able to concentrate on developing your application, rather than creating useful and reliable tests. The open-source Modernizr JavaScript framework is simple to download and install (since it's a single .js file), and it allows you to query the browser from within your program, checking to see what functionality is there. For example, if you want to know whether geolocation is supported, you can say:

if (Modernizr.geolocation) {
    navigator.geolocation.getCurrentPosition(handle_position);
}
else
{
    alert("Ack! I have no way of knowing where you are!");
}

Although Modernizr can be a terrific help in identifying what features are available, it doesn't solve the real problem—namely, gracefully handling the lack of such features. I realize Modernizr isn't designed to take on such responsibility, but perhaps someone in the jQuery community (or elsewhere) will create a library (post-Modernizr?) that goes one step beyond Modernizr, allowing us to paper over the differences between browsers, much as Prototype and jQuery did for basic JavaScript functionality several years ago.

HTML5 is coming, and some would say it's already here. If you are creating a Web application, you will do both yourself and your users a big favor by using HTML5. However, doing so does raise questions about which features you can and will include, and which browsers you intend to support. We've seen how Modernizr can help smooth over these differences and keep the Web a universal medium, but doing so will take a bit of work. Next month, I'll look at some features aimed at making the Web a more complete application framework, namely Web sockets (for interprocess communication), workers (for background threading) and local storage.