At the Forge - HTML5

HTML5 is coming, and it's going to change the way you develop Web apps. Read on to find out how.
HTML Form Elements

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.