HTML5 in the Web browser: Geolocation, JavaScript, and HTML5 extras

One of the sly games that smart managers play is attaching their current project to a big, high-profile tar ball rolling down the hill, full of momentum. Now that HTML5 has become white hot after languishing for 10 years of relative disinterest, many ideas that began as cool enhancements for the Web are latching on to the bandwagon. They may be relatively independent projects, but because they involve JavaScript and HTML, they're now part of the HTML5 juggernaut.

Consider the new JavaScript functions that let your Web page determine latitude and longitude if the code is running on a device that knows where it is. These are small enhancements that would have happened whether or not HTML5 became a buzzword that managers everywhere now feel compelled to add to their deck of slides. Yet now they're often considered in the same checklist full of HTML5 features.

[ Also on InfoWorld: "HTML5 in the browser: Canvas, video, audio, and graphics" | "HTML5 in the browser: Local data storage | "HTML5 in the browser: HTML5 data communications" | "HTML5 in the browser: HTML5 forms" ]

As we put together this series of articles about HTML5, a number of little ideas and features ended up with no place to go. They didn't naturally fit with the other articles that focused on areas such as HTML5 forms, data communications, local data storage, or the games people play with the HTML5 Canvas, video, and graphics specs. Some of these tidbits are officially part of the HTML5 standard and some are just fellow travelers, but they're all appearing in your browser soon. We had no better place to put them, so they're here.

"HTML5" geolocation
The HTML5 spec doesn't officially offer the JavaScript layer the ability to find the device's location on earth, but HTML5 and geolocation have been gathering momentum at the same time, so people tend to lump them together. The geolocation tags are technically in a separate API, if you're curious.

The features are pretty basic and originally intended for smartphones and PDAs, but they're also implemented in many desktop browsers, including Chrome 5.0 and later, Firefox 3.5 and later, and Internet Explorer 9. But just because the JavaScript object navigator.geolocation is offered doesn't mean the answer returned will be available or correct. The API thankfully allows for users to cloak their location, and many implementations ask the user for permission before revealing the geolocation object to the JavaScript code. The API returns an error of the type PERMISSION_DENIED to make it clear that the user didn't want to cooperate.

A nice feature includes a rough estimate of the accuracy along with the coordinates. There's a separate error range for the altitude because many GPS tools are less accurate in their estimates of the altitude than they are of the position on earth. The error estimates for the latitude and longitude, however, are the same, perhaps a mistake near the poles.

There are two major functions: getCurrentPosition and watchPosition. The first finds the position and the second wraps a loop around the process, generating an event only if there's a change. While getCurrentPosition is pretty straightforward, I'm still wondering why watchPosition doesn't have some parameter that defines just how much motion should trigger an event. There's just one parameter, the boolean enableHighAccuracy, that "may or may not make a difference, depending on your hardware." What is high accuracy? That's a good question. So you get to implement your own loop wrapped around the loop in watchPosition.

Much of this detail is pretty hypothetical for desktop and laptop users, even when they're using a browser that has the capability. Although desktop browsers offer the geolocation object, the computers often don't provide any mechanism for generating even a guess at the location. There are tools that can list the Wi-Fi routers in range and use the information to identify the latitude and longitude with surprising accuracy, but these haven't caught on beyond tablets and smartphones. When the device has no way of locating itself, the API generates a POSITION_UNAVAILABLE. To see if your browser supports the geolocation capabilities, try my test page at http://www.wayner.org/node/78.

HTML5 Web Workers
Who doesn't want an army of little servants working behind the scenes to make everything wonderful? The HTML5 team borrowed the imagery of this idle fantasy when they rediscovered background threads and called them "Web Workers." Now all of the hacks we've written using the JavaScript wait, delay, and pause commands to poll distant websites or animate sprites on the page can be retired and sent off to the ranch with those crazy symbols from APL.

John Resig, the genius behind the jQuery library, calls Web Workers "the coolest new feature." Although the UI specialists who work with native apps (and have known about threads for a long time) will roll their eyes at this attempt to bring JavaScript up to date with application programming circa 1990, the feature is quite novel and certainly more ornate than the average background thread. The Web Workers spec is part of the HTML5 document.

The biggest difference from threads is the way that the Web Workers objects operate in their own sandbox; they can't do anything directly to the Web page or the DOM describing it. The Web Workers must pass everything through messages, and both the Worker object and the DOM-level JavaScript must set up code to send and receive messages across the gap. This model will be familiar to everyone who's pulled out hair while trying to work around the client/server model of the Web -- think of Web Workers as little servers that sit alongside your client.

All of the major browsers except Internet Explorer (including IE9) support Web Workers today.

HTML5 iFrames
In almost all cases, progress on the Web is marked by bold strides forward with new features that enable wonderful code to be written in fewer and cleaner lines. One exception is the <iframe> tag in HTML5, a rare case of a tag that's losing some features. Don't worry, though, or start to feel claustrophobic. The functionality is merely being moved to make the integration of the iframe more seamless.

In the past, the Web designer could add scroll bars, borders, and margins to the content embedded in the iframe. Now all of that work has to be done by the HTML of the iframe itself. The Web designer coding the iframe won't have these options any longer.

That designer does get a few new options. The "seamless" attribute removes any of the borders and scroll bars, rendering the iframe like a <div> tag that acquires its information from another source.

The other option will comfort those who worry about the security of their Web pages. The "sandbox" attribute turns off many of the more dangerous features sometimes given to content inside the iframe. The main page's author needs to explicitly enable them by adding attributes such as "allow-scripts" or "allow-forms."

These new iframe attributes are useful features that will make it easier for Web page designers to collaborate with other sites, yet not worry as much about dangerous behavior. Advertisers who create more interactive campaigns will love these options because they let websites adopt the ads while providing enough security to block wayward behavior. Websites won't need to trust the ad companies as they do now.

HTML5 Parsing
No specification is ever complete because no one can even begin to imagine all of the ways that someone will use it. Over the years, the browser programmers have been surprised again and again by the ways that HTML writers found new and unexpected ways to use the tags. In the most glaring cases, the HTML creators unearthed spots where the browser developers made different assumptions. The HTML5 specification tries to spell out these places and smooth over the differences.

For example, WebKit browsers used to allow <script> tags that closed themselves with a final slash, />. Anyone who included an outside file with such a tag would find that the code worked in the WebKit world but not in the other browsers. There are a bazillion examples like this that have appeared and disappeared in different versions of the browsers.

The HTML5 Parsing spec includes dozens of steps that the browsers should use to determine the encoding delivered by the distant Web server. There are also a surprisingly large number of suggestions for how to do the right thing when working through the tags in a <table>. I'm thankful for this because I've pulled out my hair in the past when one browser (that will remain nameless) wouldn't work unless I inserted a proper <tbody> layer. Yech.

There are hundreds of different ways that the new rules will unify the browsers, almost all of them small but occasionally maddening. It would be difficult to list or even test them all. One of the more notable changes is in how the MathXML and SVG files can now be embedded inline like this:

<math> <mi>x</mi> <mo>=</mo> <mfrac> <mrow> <mo>&minus;</mo> <mi>b</mi> <mo>&PlusMinus;</mo> <msqrt> <msup> <mi>b</mi> <mn>2</mn> </msup> <mo>&minus;</mo> <mn>4</mn> <mo>&InvisibleTimes;</mo> <mi>a</mi> <mo>&InvisibleTimes;</mo> <mi>c</mi> </msqrt> </mrow> <mrow> <mn>2</mn> <mo>&InvisibleTimes;</mo> <mi>a</mi> </mrow> </mfrac> </math>

In other words, MathML and SVG are now pretty much part of regular HTML, except on older browsers, all of which will have to be explicitly supported for some time.

A number of these enhancements rise above the truly minor. Some of the so-called text-level semantic enhancements are like the microformats designed for the standard data elements floating around in text. For example, the <abbr> tag will mark all TLAs (three-letter acronyms) and allow you to embed the full definitions in case anyone is curious.

HTML5 History API
Who wouldn't want to rewrite history? The new HTML5 History object provides a limited number of ways to meddle with the browser's history. You can't take a broad sword and change the entries for different sites, but you can add new pages and rewrite the entries from the current site.

For instance, if you happen to click through n pages of a Top 1,000 list on a site and generate 1,000 page views for the ad sales department, you'll end up with 1,000 different entries in your history. If you want to go back to the page before the slideshow, you'll need to slog through 1,000 entries. JavaScript manipulation of the history can save you from this trouble.

<script type="text/javascript"> function changeURL(url, title) { if (typeof history.pushState == "undefined") { alert("Browser doesn't allow changing history with pushState"); } else { var state = {address : url}; window.history.pushState(state.address, title, url); } </script>

The main effect is to make navigation a bit more fluid and open to experimentation. The draft of the spec encourages developers to think about "nonlinear" solutions, while advising them to use their newfound power with an eye toward avoiding the confusion it might create. Rewriting history could be vexing to users and even dangerous if exercised in the wrong way, but it could also help clean up much of the ugliness where the history object is too literal.

HTML5 undo history
Many of these new features change the browser from an app that displays a distant file in a rectangle to one that allows the user to interact and change objects inside a rectangle. When humans change data, they often make mistakes and want to undo their changes. This is where the undo transaction history and the UndoManager object come in.

A major source of the events that end up in the undo transaction history list will be changes to the input boxes of forms. Giving the JavaScript programmer access to the UndoManager may make it possible to customize this interaction and produce more sophisticated forms.

HTML5 layout enhancements
One of the biggest new developments in HTML5, at least in terms of raw features, is the large collection of tags added to mark different sections of the document. Although the original HTML offered tags to mark the beginning and end of significant parts of a document's structure, there weren't many of them beyond the header (<h1> through <h6>) and the paragraph (<p>) tags. The rest were largely devoted to typographic signals such as bold (<b>) and italics (<i>).

Many of the new layout tags recognize what Web developers have been building on their own. There are now tags like <header> and <footer> that tell the browser to put which information at the top and bottom of the pages. Some of these will add confusion. The <section> tag, for instance, operates similarly to the <div> tag, so there will be some who use <div> where others use <section> and vice versa.