Geolocation, Web Workers, History manipulation, iFrame sandboxes, and other HTML5 specs laying the groundwork for a safer and smarter Web
[ 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.
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.
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:
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.
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.
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.
Many of the basic elements are supported across all major browsers, but the same can't be said for a number of the elements that seem less obviously useful. At this moment, the <figure> tag for attaching a movable figure to a section of text will work in Firefox 4.0 but not in Safari. The <ruby> tag used to annotate Asian symbols sort of works with Safari but not with Firefox.
Saying that a tag is "supported" here is not as straightforward as with other HTML5 features -- the semantics require more specification. It's one thing to write down requirements to store data, but it's another to specify just what a browser should do when laying out blocks of text. Even after the browsers start recognizing these tags, the browsers will probably choose to display the information inside the tags in slightly different ways.