At the Forge - Communication in HTML5

HTML5 gives Web applications new communication features.

Last month, I took an initial look at HTML5, the new standard for HTML that increasingly is supported by popular browsers. HTML5 includes a large number of different technologies and solutions, and it's being rolled out in a piecemeal fashion. Some parts of HTML, such as the abbreviated DOCTYPE declaration at the top of a document, can be used already. Other parts, such as new elements for HTML forms, are not quite ready yet for mainstream use, unless you are willing to use JavaScript to handle elements in browsers that lack support for those features.

For me, the improved form tags and expanded semantic markup for sections, headers and the like are both important and useful advances. But in many ways, I believe some of the most important improvements are a bit harder to understand and will take longer to catch on. These are improvements in how different pages may communicate with one another within the same browser or how the Web browser may communicate with outside resources.

To date, it has been difficult, if not impossible, for a program running in the browser (that is, with JavaScript) to create a mashup between two data sources or interact with another open window. This was because of a combination of historical, practical and security concerns, all of which were understandable. But today, we want our browsers to do more. Indeed, most modern applications are being developed for the browser, and if we can somehow push more information and intelligence to the browser, we'll both reduce the load on our servers and improve the responsiveness of the application.

A number of features in HTML5—and yes, some of these features aren't really part of the HTML5 specification, but I'll pretend they are for the purposes of this column—are designed to solve precisely this problem. These features aren't meant to make it easier to create Web pages, but rather Web applications. Specifically, I'm talking about interpage communication, WebSockets and threads, known as Web workers. Each of these topics probably deserves a column to itself, so I admit that the examples I provide here are meant to give you a taste of what's possible, rather than a comprehensive tutorial or example. Nevertheless, I hope you'll become excited about the possibilities raised here, and perhaps you'll even think of new and interesting ways to make use of these features.

Interpage Communication

The basic building block of the Web is the page, and more specifically, the page of HTML. Sure, modern Web browsers can display all sorts of different formats, but for all intents and purposes, when you talk about a Web app, you're talking about one or more pages of HTML. Nowadays, that page can be modified via JavaScript, using a variety of different techniques that often are lumped together with the Ajax name, regardless of how true or appropriate that is. Ajax has complicated things somewhat, removing the one-to-one correspondence that used to exist between HTTP requests and HTML pages. Although this means the flow of our applications has become more complicated, Ajax has made the Web a far more useful and friendly platform for users, and even for developers.

For many years, Web browsers were one-page-per-window affairs. If you wanted to browse three pages simultaneously, you needed to open multiple windows. Modern browsers all support the use of tabs, with some users (like me) abusing this feature quite a bit, opening dozens of tabs each day and then taking my sweet time to read and close the contents of each one. Given that all of these tabs (or windows) are running within the same program, it should be possible for them to communicate using a combination of JavaScript and HTML.

Perhaps this should be the case, but to date, it has not been possible. That's due to privacy concerns. You didn't want one Web page to be able to read from or write to another page without permission, and there wasn't a standard that would provide such permission. This is true not only in the case of two separate pages, but also in the case of two iframes on the same page, which might want to affect each other.

Now, if you're thinking you actually have been able to do this in the past without any hoopla, you might be right. It's true that an iframe can communicate with, and even modify, its parent window, but only if the two pages have the same origin. HTML5 changes the rules of the game by allowing pages to communicate with one another, even if they have different origins.

This works as follows. The sending page invokes the postMessage() method on the window or iframe that should receive the message, along with the expected origin of the receiver. For example, let's create a very simple HTML file that contains little more than an iframe (Listing 1). For now, ignore the JavaScript event handler that is defined there. I'll get to that in a bit.