This book is primarily about HTML5 for web designers, and what HTML5 delivers for us is, well, mixed.

But it’s not fair for that impression to characterize the entire HTML5 spec. Many of the features now in HTML5 began life in the Web Applications 1.0 spec (www.whatwg.org/specs/web-apps/2005-09-01/), and it shows. HTML5 wasn’t really written for designers. Instead, it was written more for developers. And from a development point of view, HTML5 looks far more interesting, even for us as designers, as we’ll see in a moment.

So, in this chapter, we’re going to run through some of the important web app–oriented features of HTML5 that are, in some ways, the real meat of HTML5.

First, though, let’s take a quick look at the (rapidly changing) browser landscape for HTML5 web app development.

HTML5 Web App Browser Support

For all the hype, HTML5 browser support for web app features (on the desktop at least) is still a bit of a downer. But we can’t blame that on the spec. Ian Hickson and the WHATWG have bent over backward to make HTML5 as implementor-friendly as possible, documenting browser behavior in a way that’s never been done before.

Though Microsoft has thankfully embraced auto-updates for IE, legacy IE versions (particularly IE8—the last version of IE for XP) will be with us for years to come. In the business sector, many organizations still have strict policies managed by IT departments regarding updates and adoption lags by several releases. In the consumer market, many are getting the latest versions of IE now without even knowing it, but others on older operating systems won’t see that benefit until they bite the bullet and update to a new version of Windows. IE8 is rapidly becoming like (the now thankfully dead) IE6 in the sense that it’s the new hard-to-shake, pain-in-our-collective-behinds browser that will hang on as stubbornly as Windows XP does. Microsoft support for Windows XP is over as of April of 2014 and hopefully this will help force at least business users to upgrade. Still, we should expect to support home users for at least a few more years. Here are the worldwide operating system trends, but always check your own analytics data to see what’s relevant for your audience: http://gs.statcounter.com/.

But the next decade is actually looking much better than the previous one. Chrome and Firefox are now on release cycles measured in weeks. This is what Jeff Atwood said in his post “The Infinite Version” (www.codinghorror.com/blog/2011/05/the-infinite-version.html):

Microsoft, desperate not to be left behind, not only is catching up as fast as it can but is innovating too—from hardware-accelerated Canvas and SVG to a proper CSS layout system in IE10—and it’s implementing more standards than most other browsers in IE11. Microsoft is also speeding up its browser releases, aiming for annual version updates (see www.computerworld.com/s/article/9215766/Microsoft_quickens_browser_pace_with_IE10_goes_for_annual_upgrades), and pushing HTML5 hard for its native, installed apps in Windows 8. Updating IE on an annual basis is still slower than Chrome or Firefox, but it’s a huge improvement on IE’s legacy of slow releases, and pushing auto-updates now means adoption of the latest should go up much more quickly, and we designers/developers can start using cutting-edge features faster.

In the meantime, HTML5 polyfills will keep being refined and enhanced to fill the gaps as best we can until legacy IE (and Windows XP) truly dies out: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills.

Browser updates and innovation are as important as the spec itself. As Ian Hickson says, a spec that doesn’t get implemented exists only as fiction. But this raises other issues: how do you develop for “modern” browsers when they’re being updated every couple of months? Part of the answer is feature detection, which we’ll look at shortly.

Then there’s mobile . . . .

HTML5 on Mobile: WebKit and Beyond

If HTML5 web app development in the here-and-now has one saving grace, it’s mobile (specifically iOS and Android) web app development. The support for HTML5 features in WebKit (the saucy minx behind iOS’s and Android’s browsers) is solid and improving all the time. But we can’t assume the mobile web means WebKit even if it dominates, just as we don’t develop exclusively for IE on the desktop even when it dominates.

In fact, we can’t even assume “WebKit” refers to a consistent platform, either. In A List Apart’s “Smartphone Browser Landscape” article from December 2010, Peter-Paul Koch writes the following (www.alistapart.com/articles/smartphone-browser-landscape/):

That was as true then as it is now, if not more so. For example, there are two different Android browsers from Google —the stock Browser app and Chrome for Android —and that’s not taking into consideration Android OS fragmentation, which is in and of itself a bit of a nightmare and means that every version of “Android Browser” could be different.

Even talking about “mobile” as though it’s synonymous for iOS and Android is problematic. The mobile world is so vast—including the “smartphone” market, which has plenty of cheap, under-powered Android devices, legacy iOS devices, and even still legacy BlackBerry devices. It’s a mistake to generalize at all. There’s also Opera Mobile and Mini and Firefox for Mobile. (In fact, there’s a whole Mozilla mobile platform, which we’ll discuss in the following section.) And then there’s the Windows Phone platform and Internet Explorer Mobile.

Mobile Is a Moving Target: Microsoft’s Big Push

The mobile landscape has long been in a state of flux, thanks in no small part to the innovative pushes into this market by lots of different players. Surprisingly, one player who was late to the game was Microsoft, which finally got in seriously in 2010.

Microsoft’s modern Windows Phone platform launched as “Windows Phone 7” in late 2010 and shipped with our old friend—and “by friend” I mean sworn enemy—IE7 (well, IE7 and a half). Microsoft thankfully started rolling out IE9 Mobile in late 2011 as part of its Windows Phone 7.5 (a.k.a. “Mango”) update. It then updated this to Windows Phone 8 in 2012, which is the current version at the time of this writing and currently uses mobile IE10 as its browser. The version 8 update vastly matured the Windows Phone platform, and as far as mobile browsers go, IE10 is surprisingly compliant with standards.

Microsoft has unified its desktop and mobile browser code base, and given it is pushing HTML5 hard across the board (especially in IE10) and can push out mobile browser upgrades quite efficiently (unlike the desktop, which as we noted will still be hampered by corporate IT departments), we’ll ideally see IE Mobile continue to advance in future releases. At the time of this writing, it still lags mobile Safari a bit but is generally as up to date as Mobile Opera, which is a huge improvement.

In the meantime, however, IE10 Mobile is another example demonstrating that the modern mobile world isn’t just iOS and Android. At the time of this writing, Windows Mobile adoption is still pretty low, and Android and iOS are definitely the largest players, but Microsoft isn’t going to let the mobile market get away easily. Additionally, it has been throwing huge amounts of money into marketing its Surface platform, which uses the full version of IE in sync with the desktop version. The unification of IE’s code base across tablets and desktops means that, more than any other platform, developers are going to have to start treating the IE market as a single whole that works on multiple devices, rather than drawing a clear line between the mobile, tablet, and desktop versions. And viewed that way, IE is still a serious contender.

We also need to keep mobile use in perspective. Mobile, and particularly responsive web design, may be, like, so hot right now, but if only 8 percent of your audience uses smartphones to access your site, you need to weigh how you spend your time for that 8 percent versus the other 92 percent of users. (On the other hand, if your numbers are the reverse, go nuts!) Check your stats in Google Analytics or in (shameless plug ahoy!) Ninja For Google Analytics at http://itsninja.com, which I designed for web designers and developers so you can have the relevant Google Analytics data at your fingertips.

Firefox OS: Mozilla’s Ambitious Mobile Platform, and the WebAPI

While companies like Microsoft try to push their own platforms, part of which involves the Web, Mozilla has been working hard at turning the Web into a mobile platform, especially with its Boot to Gecko (B2G) project, which was released in 2013 under the name Firefox OS for better brand recognition. You can find its impressive microsite online here: www.mozilla.org/en-US/firefox/os/.

At the time of this writing, Firefox OS phones are available in Spain, Venezuela, Colombia, and Poland. Seventeen operators support it, none of which are in the United States, and it’s available on only two different devices. It hasn’t exactly exploded out of the gate, but it does represent a unique innovation over other mobile platforms: it’s entirely web-based. It’s built on another Mozilla project, called WebAPI.

The WebAPI project has set its sights high and aims to fill the many large gaps in using web technology as a mobile platform and includes APIs for things like a phone dialer, SMS functionality, an address book, camera access, device settings, games, and more. It states its goal as “pushing the Web to include—and in places exceed—the capabilities of competing stacks.

This means you can have a phone powered entirely by web apps, and you can see how they run simply by viewing the source, just like any other web app or web site. The WebAPI project is beyond just supporting Firefox OS. Firefox OS is a great place for the WebAPI to bring itself to the forefront, but there’s no reason that you couldn’t build a host of web-driven applications on other platforms that use the WebAPI.

By all accounts WebAPI and Firefox OS are functionally doing quite well. For example, way back in 2012 The Verge reported the following from the Mobile World Congress (www.theverge.com/2012/2/27/2827659/mozillas-boot-to-gecko-project-the-internet-is-your-phone-hands-on):

This is “HTML5” in the broadest sense of existing and new (particularly Mozilla-invented) web technology, not the HTML5 specification per se. Nevertheless, it demonstrates the incredible potential for web technology beyond HTML5 and the power of the Web as a platform in its own right.

It also shows the development of web technology is not purely a matter of the WHATWG versus the W3C, as we saw way back in Chapter 1. It’s possible for players such as Mozilla to do plenty of innovation in their own time (and on their own dime) and (as Mozilla is doing) take their work to the W3C to ensure it becomes a patent-free standard all can use and implement.

Whether adoption of the Mozilla platform will ever catch on is yet to be seen. At the time of this writing, it’s not exactly tearing the market apart, but it’s still early. What Firefox OS does show is that there are resources from large players on the Web committed to driving innovation in mobile and that open web technology, and thus eventually web standards, can play a big role in that.

HTML5 Mobile Compatibility

For more on the current state of HTML5 mobile compatibility on a wide variety of platforms, Maximiliano Firtman has put together an excellent chart with 15 mobile browsers, and a variety of HTML5 and related web technologies and APIs, that’s available here: http://mobilehtml5.org/.

That wraps up our quick journey through HTML5 and mobile, so now let’s get back to HTML5 and web app development.

HTML5-Powered Content Management

One key reason designers should have at least some interest in HTML5’s web app features on desktop and mobile is content management systems. CMSs are the one category of web apps (broadly speaking) we all rely on for our client or company work.

For example, it would be great to see CMSs take advantage of the History API for fast page loads, local storage (for auto-saving form entries, perhaps), and maybe offline functionality for mobile blogging/content editing. (We’ll touch on these features in a moment.) There’s also the Mozilla HTML5 Image Uploader (http://hacks.mozilla.org/2010/02/an-html5-offline-image-editor-and-uploaderapplication/) that uses a bunch of HTML5 technology such as the offline application cache, local storage, Canvas, and drag and drop and that serves as a good indicator of how HTML5 can enhance the CMSs we (and our clients) use day in, day out. The sooner we suggest these features, the sooner they’ll be implemented.

The JavaScript Age

While we may spend a lot of time in the trenches wrangling CMSs, it’s worth keeping an eye on the big picture too. The overarching theme of these new features—and possibly the future direction of the Web itself—is they’re all about JavaScript APIs and not hypertext per se. In a sense, hypertext is now the tail wagged by the JavaScript dog, especially in terms of web applications.

The problem of marking up documents has been solved. Over the next decade or so we’ll see major improvements in writing applications, as HTML5 (and related) features for web apps become baseline standards. After all, HTML5 is largely a web apps spec from the mid ’00s.

This is a (small) part of the reason we’re perhaps entering the JavaScript Age, as Mike Driscoll puts it in “Node.js and the JavaScript Age” (http://metamarketsgroup.com/blog/node-js-and-the-javascript-age/):

Or, put another way, Jeff Atwood in “The Principle of Least Power” said the following (www.codinghorror.com/blog/2007/07/the-principle-of-least-power.html):

The question is, what will this mean for the humble web page?

JavaScript Killed the HTML Star

In a sense, we have been exploring this new frontier since the whole “Web 2.0” thing kicked off. So, we shouldn’t be surprised that the thrust of new developments are JavaScript-related.

The humble web page has been incredibly robust and resilient. With billions and billions of them out there, and billions more being made, they’re not going away any time soon. But the hugely inefficient click - full-page refresh - click - full-page refresh paradigm in high-profile sites may not be around for long in light of things such as the History API, which we’ll look at in a moment.

We’ve achieved some pretty incredible things on top of the basic web page. Uber-nerds get excited about complex functionality (as is happening now with web apps–oriented HTML5 functionality), which then gets abstracted into a library, plug-in, or framework and becomes almost trivial for designers to drop into their sites.

While this is wonderful for us, it does mean the lines between web page and web application will continue to blur. Is a modern web site a JavaScript/Ajax/HTML5-powered application that serves content or a collection of simple, linked pages . . . something in between? Right now the answer is “all of the above,” but it will be interesting to see at what point the amount of JavaScript on our site makes it more “app” than “page.”

For example, consider the amount of functionality that can be bolted onto a traditional web page through JavaScript. JavaScript for animation; JavaScript for SVG (with Snap.svg and Raphaël, as we saw in Chapter 11); JavaScript for page state (which we’ll look at later in the chapter); JavaScript for A/B testing your design; JavaScript for new CSS layout engines (for example, http://code.google.com/p/css-template-layout/); JavaScript for CSS preprocessing; JavaScript for graphics and games (Canvas and WebGL, as we saw in Chapter 9); JavaScript for audio and video controls (Chapter 10); and even JavaScript for decoding MP3s (http://hacks.mozilla.org/2011/06/jsmad-a-javascript-mp3-decoder/ , which works around the patent issues we discussed in Chapter 9 and is pretty incredible in its own right).

Phew.

JavaScript is the wrapper around (or enabler of) all this functionality, some of which is HTML5, and some of which is not. But how long until we go all the way—if indeed we should—and launch bare-bones HTML pages with everything else abstracted into essentially one big JavaScript app? If some web apps are now being delivered as simply JSON data and a client-side JavaScript application (as we touched on earlier), why not web pages?

Well, there’s SEO, but the situation is rapidly changing there. In November 2011 Google’s Matt Cutts said the Googlebot was already spidering JavaScript/Ajax comment systems, at the very least (http://searchengineland.com/google-can-now-execute-ajax-javascript-for-indexing-99518); Google can crawl the (problematic) hashbang (#!) URL format; and the HTML5 History API provides new possibilities we’ll look at next. (Apart from SEO, issues such as maintenance are, however, quite legitimate objections!)

It’s clear which way the wind is blowing. Think how far we’ve already come from the days when JavaScript was synonymous with horrendous DHTML and clunky rollover scripts. Now it has become the de facto programming language of the Web.

Nevertheless, we shouldn’t get too distracted by the technology. It’s fun to explore all the possibilities that modern JavaScript frameworks have to offer, but the evergreens such as great copy, a great user experience (especially when measured in hard numbers such as conversion and/or engagement rates), and designing to generally get the hell out of the way will still matter above all else. Some things just never go out of fashion, and as long as our JavaScript frameworks are implemented in service of those larger goals, we’ll stay on track with what the Web was meant to do. (We’ll touch on this a little more when we look at performance-based design in the final chapter.)

But before we get there, let’s quickly run through these new web app–oriented features and how we can detect them (along with some resources for further reading).

Modernizr, When Can I Use . . . , and Polyfills

Browser releases have become incredibly fast. As we touched on earlier, Chrome and Firefox aim to roll out updates in weeks. This alone makes it incredibly difficult, if not outright foolhardy, to try to detect which browser version gets which functionality.

Browser detection has never been a great idea. You still occasionally run into antiquated web sites that tell you to “upgrade” your bleeding-edge version of Chrome or Firefox to a “modern” browser like Internet Explorer 7, because that’s all the developers could foresee at the time. It’s hard to detect browsers that don’t yet exist, but when the Web moves forward and your page is outdated, it’s an embarrassment. Focusing on browser detection is a losing game that requires constant tinkering.

HTML5 Web App APIs

Let’s jump into the new HTML5 (and thereabouts) web app functionality.

(Browser stats in this chapter come from http://caniuse.com, which goes back only to IE 5.5, Firefox 2, Chrome 4, Safari 3.1, Opera 9, iOS 3.2, Opera Mini 5, Opera Mobile 10, and Android 2.1. Windows Phone 8’s current browser is IE10 with slight differences. I’m leaving out Opera’s mobile browsers and Firefox Mobile for simplicity’s sake, but keep in mind the rapid changes in the very broad mobile market we discussed earlier.)

History API (pushState)

Let’s start with the HTML5 History API (also referred to as pushState). URLs have been abused to all hell for fun and profit in the Ajax era. This is especially true with the hashbang (#!) approach you may have seen on Twitter in the past, Facebook, and sites such as Gawker. (Typing http://twitter.com/lukestevens used to return http://twitter.com/#!/lukestevens, but Twitter is moving away from this behavior.)

Some people think this is, like, the worst thing ever, while others think it’s the price of progress. See the debate, with links, here: http://danwebb.net/2011/5/28/itis-about-the-hashbangs. (That’s from Dan Webb, who was in charge of undoing Twitter’s hashbang URLs, as he tweeted here: https://twitter.com/danwrong/status/171680703824662528.)

In any case, the History API goes some way to solving this. With the History API we can still load a chunk of new content into your page with Ajax (or similar), but we can also update the URL in the user’s location bar (and browser history) to make the whole process look like a very fast page request.

Mind you, it takes some work to fake the whole backward/forward page navigation thing. You can read Mark Pilgrim’s detailed write-up and tutorial here: http://diveintohtml5.info/history.html. SEOmoz also covered the History API in “Create Crawlable, Link-Friendly AJAX Websites Using pushState()” (www.seomoz.org/blog/create-crawlable-link-friendly-ajax-websites-using-pushstate).

This would be a handy addition to the modern CMSs we offer our clients (at the very least). We’d get fast Ajax page loads without confusing not-necessarily-technical clients, who’d still see the new URL and have their back button work predictably.

It’s also something we can consider implementing in a progressive way. There’s no IE9 or older support (though it is in IE10+), Chrome support is good, Safari support is buggy, and Opera support arrived only in 11.5+. (On mobile, iOS 4.2–4.3 support was buggy, iOS5+ support is solid, and Android inexplicably dropped support in 4.0 but added it back in 4.2 and has maintained it since.)

But there is History.js (https://github.com/balupton/History.js), which aims to provide fallback support for unsupported browsers and smooth out the quirks in current implementations. The creator of History.js, Benjamin Lupton, discusses the pros and cons of the different approaches to handling URLs in “Intelligent State Handling” (https://github.com/browserstate/history.js/wiki/Intelligent-State-Handling).

(Remember, though, hashbang URLs are forever, even if used only as a fallback for older browsers. If someone uses a hashbang URL to link to your site, then that’s a URL that needs to be maintained indefinitely. Falling back to full-page loads may be a better way to go.)

For current browser support stats for the History API, see http://caniuse.com/#feat=history.

HTML5 Web Storage (and JavaScript-Rendered CSS)

Web Storage (also known as localStorage) is often described as “cookies on steroids,” given it can store up to 5MB of data (key-value pairs) on the client (the actual size limit is up to the browser and no longer specified in the spec, but 5MB was previously recommended and is still a good rule of thumb). Unlike cookies, the data isn’t automatically sent back to the server, and it doesn’t have an explicit expiry date. (Web Storage was originally part of the HTML5 spec but has since been spun out into its own specification, still edited by Ian Hickson: http://dev.w3.org/html5/webstorage/.)

This kind of storage could be used to save web app data locally, whether it’s a saved game state (so the user can resume where they left off) or a document the user is working on.

In terms of web design, we could use localStorage to save the output of a CSS preprocessor. In the past few years, CSS preprocessors (such as LESS and SASS) have become all the rage, offering advanced CSS syntax and features such as variables, mixins, and better inheritance. You write the code using the new syntax, and the software spits out normal CSS a browser can understand. You can output the CSS as a one-off or automatically on the server.

You can also do it on the client side with JavaScript and Less.js (http://lesscss.org/). The Less.js script uses Web Storage to cache the outputted CSS, making subsequent requests for the CSS extremely fast.

This is a pretty profound development. We can now use JavaScript to generate CSS however and whenever we like and store it locally. No more faffing about with server-side scripts to do the parsing, during development at least. (For production it should be compiled to normal CSS; otherwise, those without JavaScript won’t get your CSS either, and as we covered in Chapter 4, that’s A Bad Thing™.) It’s simple, it’s powerful, and it works right now.

(By the way, I’m not advocating LESS over any other flavor of CSS preprocessor. If you decide to go down this route, use whatever floats your boat.)

For more on Web Storage, see the following:

• Mark Pilgrim’s chapter from Dive Into HTML5: http://diveintohtml5.info/storage.html
• Opera’s “Web Storage: easier, more powerful client-side data storage” article: http://dev.opera.com/articles/view/web-storage/
• Mozilla Developer Network’s “DOM Storage” article: https://developer.mozilla.org/en/dom/storage

Web Storage is currently supported in IE8+ and all other modern desktop browsers. For current usage statistics, see http://caniuse.com/#feat=namevalue-storage.

Database Storage

Web Storage sounds great, for some kinds of data. What about database storage on the client side?

Politics, that’s what.

The no-longer-maintained Web SQL Database spec (www.w3.org/TR/webdatabase/) has been implemented in some browsers using SQLite (Safari, Chrome, and Opera on the desktop), along with Mobile Safari and Android. But Microsoft never implemented it, and Mozilla is philosophically opposed to it (see http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/).

Mozilla provided an alternative known as IndexedDB and implemented it first in Firefox 4 and in every version thereafter. Microsoft got on board with IE starting in version 10, Google started implementing it back in Chrome 11, and even Opera started support in version 17. Safari is the only holdout, seemingly committed to WebSQL, and mobile support at the time of this writing is limited to Android Browser 4.4 and IE Mobile 10.

Unfortunately, there’s no single solution for this to date. Developers who want a client-side database must roll two solutions or not support Safari.

HTML5 Offline (Application Cache)

HTML5 allows developers to keep their web apps (or sites) running even if the client is offline—a common concern in the mobile world where a lost connection is just a tunnel away.

How? By specifying which URLs the browser should (and shouldn’t) cache in a manifest file, which you reference by using the manifest attribute on the <html> element for every page of your web app.

It’s one of those simple-in-theory-but-complicated-in-reality features that puts it beyond the scope of this book. So, if you want to know more, check out the following:

• The web developer edition of the HTML5 spec, which has a lengthy explanation and tutorial: http://developers.whatwg.org/offline.html
• Mark Pilgrim’s chapter in Dive Into HTML5, which covers this feature in considerable detail, including debugging information: http://diveintohtml5.info/offline.html
• Dev.Opera’s handy introduction: http://dev.opera.com/articles/view/offline-applications-html5-appcache/
• A List Apart’s article “Application Cache is a Douchebag” by Jake Archibald, which covers many of the still relevant frustrations and issues with implementing the Application Cache API: http://alistapart.com/article/application-cache-is-a-douchebag

Bringing some of these features together (along with the Geolocation API that we’ll look at soon) can create robust, mobile, HTML5-driven web applications. Now we just need to wait for the desktop to catch up.

And by “desktop” I mean Internet Explorer users, since IE didn’t support HTML5’s offline functionality in IE9 and older but does support it in IE10+. The other desktop browsers do support it, as does (importantly!) iOS , Android, and IE for Windows Phone. (For current usage statistics, see http://caniuse.com/#feat=offline-apps.)

Geolocation API

The Geolocation API provides a standard client-side way for a web site to detect the user’s location. Geolocation on the Web isn’t new. Plenty of sites use your IP address to work out your location (at least at the country level) so they can do the following:

• Serve you region-specific ads
• Lock you out of certain services (as anyone living outside the United States knows all too well!)

It can even be done on the client side when you load any Google Ajax API (which you may already use to load jQuery—see http://googleajaxsearchapi.blogspot.com/2008/08/where-is-my-current-user.html) or on the server side using something like www.ip2nation.com/.

The good news is you don’t need permission to do old-school geolocation based on your user’s IP. The bad news is it’s not always that accurate.

The new Geolocation API, on the other hand, tries to use whatever location data is available, including the following:

• GPS
• Wireless network (as recorded by Google Street View)
• Cell tower locations
• IP address (it’s agnostic as to where the data comes from)

It can then provide details about latitude, longitude, altitude, direction, speed, and even accuracy (when it’s available). Previous locations can even be cached (to map out a trip, for example).

But you can forget about getting this data without anyone knowing. The device must ask for your permission before it can use it.

The Geolocation API isn’t part of HTML5 per se. (You can see the spec here: http://dev.w3.org/geo/api/spec-source.html.) But it’s cool and opens up some interesting possibilities with mobile web sites. The spec suggests the following:

• Blogging (or status updates) with location data attached
• Showing a user’s position on a map
• Turn-by-turn navigation
• Tour-guide web apps
• Location-specific weather or news widgets

And remember, it all happens in the browser—no server-side IP detection required.

The Geolocation API is well supported in all modern desktop and mobile browsers, with the sole exception of Opera Mini. (For current usage statistics, see http://caniuse.com/#feat=geolocation.)

For more information, see the following:

• Mark Pilgrim’s Dive Into HTML5 Geolocation chapter: http://diveintohtml5.info/geolocation.html
• The “A Simple Trip Meter using the Geolocation API” tutorial: www.html5rocks.com/tutorials/geolocation/trip_meter/
• Firefox’s user guide to “Location-aware browsing”: www.mozilla.com/en-US/firefox/geolocation/

Other APIs That May Be of Interest to You

Other new APIs in and around HTML5 allow developers to do the following, in the words of Remy Sharp (Introducing HTML5, 2011):

These APIs include cross-document messaging (IE8+ up, all modern desktop and WebKit mobile browsers), which allows documents on different domains to send information back and forth. This could be useful for a widget on one site that needs to pull data from another domain. This MSDN article provides a useful overview of the issues and technology: https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage.

Web Workers (IE10+, Firefox 4+, Safari 4+, all recent Chrome and Opera, limited mobile) offers an API to run scripts concurrently in the background, instead of the one-at-a-time-while-everything-freezes-until-it’s-done approach we have now. Wikipedia has a useful, brief overview: http://en.wikipedia.org/wiki/Web_Workers.

Web Sockets (supported across the board with the exception of Android Browsers before 4.4 and Opera Mini) allows efficient bi-directional communication between browser and server. At its most basic, this could be handy for a chat room application. For more resources, see www.websocket.org/aboutwebsocket.html.

The File API (supported by all platforms except Opera Mini and IE Mobile) lets us read and write files and directories, as demonstrated in this neat music player: http://antimatter15.github.com/player/player.html. There’s also a useful tutorial here: www.html5rocks.com/tutorials/file/filesystem/.

Oh, and there’s also the Drag and Drop API (supported by all major desktop platforms and only IE for mobile), which is, according to every single person who has ever come into contact with it (including Ian Hickson, who added it to the spec), pretty horrible. Drag and Drop (DnD) was added to IE5—yep, 5—by Microsoft in 1999, and other browser vendors also implemented it. So, Hickson reverse-engineered it (à la Canvas), documented it, and added it to the HTML5 specification in the spirit of documenting what already works. So, now we have widely supported Drag and Drop. (You can see Hickson’s account of the process here: http://ln.hixie.ch/?start=%201115899732&count=1.)

Why not just use JavaScript for drag and drop? For on-page elements you certainly could, but the thing about the (somewhat brain-damaged) HTML5-via-1999 DnD API is it lets you drag and drop all kinds of content to and from other applications. There’s a basic tutorial here: www.webdesignerdepot.com/2013/08/how-to-use-html5s-drag-and-drop/.

What Comes Next: HTML 5.1

So far, everything we’ve been talking about is included in the HTML5 spec, which at the time of this writing is fairly well locked in and should be finalized in 2014. Work on the next spec, titled HTML 5.1 (previously, and cutely, “HTML.next”), began in the middle of 2012 when the HTML5 spec was finalized.

5.1 is scheduled to itself to have a “last call” sometime in 2014 with a final recommendation going out in 2016. In the meantime, they’ll have final revisions on a working candidate with all new work going into HTML 5.2. If the W3C follows this schedule, we should all be able to eagerly anticipate HTML6 by 2034 or so, and in the meantime, the rest of the Internet will have a field day coming up with other ideas on what HTML6 should be (my favorite: “The Spec that Brings us Freedom” at http://html6spec.com/).

HTML 5.1, to date, doesn’t contain much to write home about with one exception: the encrypted media extensions (EME) specification, which allows for locking content (DRM) of not just video or video streams but images, text, and JavaScript files—anything that’s served with a web page could be “protected” by EME and kept locked down from easy inspection.

This has obviously caused a lot of controversy, which we covered in more detail in Chapter 10. The Electronic Freedom Foundation is raising alarms and calling for boycotts of Netflix in response. The foundation summarized a valid concern for EME in a blog post (https://www.eff.org/deeplinks/2013/10/lowering-your-standards), saying this:

Scary stuff. These are perilous times for the Web, and the next few years may drastically change the course of its future.

Along with EME in HTML 5.1 could be the Media Source Extensions spec, which is currently its own specification (https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html) and, as you might recall, the other piece required to roll video products like Netflix into a 100 percent pure HTML <video>.

You can find the latest Editors draft of the HTML 5.1 spec here: www.w3.org/html/wg/drafts/html/master/single-page.html.

Wrapping Up

There you have it—a quick run through HTML5’s web app–oriented features. As you can see, HTML5 is about introducing a native web apps platform. That isn’t surprising considering the spec started as Web Applications 1.0 and Web Forms 2.0.

HTML5 is also just a stepping stone in the evolution of web applications, albeit a very important one and one that has been a long time coming. Post-HTML5 developments (especially from Mozilla in mobile, as we discussed earlier) are continuing at a break-neck pace. They’ll continue to be called HTML5, as (I believe) Mark Pilgrim put it:

It’s an exciting time for the Web. Hold on tight; it’s going to be one hell of a ride.