Geolocation, Web Workers, History manipulation, undo, iFrame sandboxes, and other HTML5 specs laying the groundwork for a safer and smarter WebFollow @peterwayner
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
All of the major browsers except Internet Explorer (including IE9) support Web Workers today.
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.
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.