If you don’t care about IE you can do it as simply as:

<form method="post" action="/">
<p>
    <label for="username">Username:</label>
    <input type="text" name="username" id="username" autofocus="autofocus"/>
</p>
<p>
    <label for="password">Password:</label>
    <input type="password" name="password" id="password" />
</p>
<p><input type="submit" name="login" value="Login"/></p>
</form>

Since autofocus is boolean you technically don’t even need to specify an attribute value.

To do it with IE in mind you could use the following JavaScript below the form (no library needed):

function focusForm(){
    setTimeout(function(){
        try {
            // id of element to focus on
            var elem = document.getElementById('username');
            elem.focus();
            elem.select();
        } catch(e){}
    }, 50); // setTimeout to fix IE bug
}
focusForm();

Note the use of select() so if the form reloads due to an incorrect password the field is not just in focus but the contents highlighted. There is also a setTimeout() since IE, at least some older versions have trouble with this if it happens too quickly. 50 should be fast enough that it won’t be noticed by humans.

See how simple that is? No excuses for not fixing this .

Here’s an example based on jQuery and jQuery.cookie. It’s designed to turn objects into JSON and store the JSON representation. On retrieval it restores the object. This doesn’t handle things like expiring cookies (it simply defaults to 365 days). I just had this around from an old project with these very specific requirements and figured I’d post it as-is in case it can help anyone and to demonstrate. This isn’t ideal for reuse, but for someone playing with the idea, maybe it will motivate .

function storeData(type, obj){
    var data = jQuery.toJSON(obj);

    // If using a modern browser, lets use localStorage and avoid the overhead
    // of a cookie
    if(typeof localStorage != 'undefined' && localStorage !== null){
        localStorage[type] = data;
    }

    // Otherwise we need to store data in a cookie, not quite so eloquent.
    else {
        jQuery.cookie(type, data, { expires: 365, path: '/' });
    }
}

function loadStoredData(type){
     var data;

    // If using localStorage, retrieve from there
    if(typeof localStorage != 'undefined' && localStorage !== null){
        data = localStorage[type];
    }

    // Otherwise we have to use cookie based storage
    else {
        data = jQuery.cookie(type);
    }

    // If we have data, lets turn it into an object, otherwise return false
    if(data){
        return jQuery.secureEvalJSON(data);
    }
    return false;
}

Pretty simple right? It’s still a key/value API.

Firefox has two basic abilities, you can clear cookies, or you can browse and delete cookies. That’s great but not terribly clear that there’s more than cookies.

Chrome as far as I know has no cookie browser like Firefox has, but (edit: Erunno notes in the comments you can via chrome://settings/cookies) explicitly lets you “Delete cookies and other site and plug-in data”. That’s pretty good.

Today, I think Safari’s UI is the closest to perfect. Each hostname shows exactly what it has. My only gripe is that Safari doesn’t let you see what’s there. That’s a “power-user” feature however and I think it does an adequate job regardless.

Websites use more than just cookies these days. I discussed this a little over a year ago. The reason evercookie is controversial is that browsers don’t quite give users the level of control (real or perceived) that they expect for objects other than cookies.

Here is another use case for why this is needed. Google Analytics is used on perhaps half the internet’s websites. It sets a cookie every time. That means 230 bytes added to every http request for a lot of websites. Google could switch to localStorage and free up that 230 bytes. While they technically could do this, in practice, this could create a firestorm of attacks against them. The problem is it would be spun as Google trying to evade cookie deletion and and a privacy violation. The same storm that evercookie created. I suspect that’s why it hasn’t been done to date. The truth is the Google Analytics team has done a lot for improving performance including making it entirely async. But this move would be controversial.

It’s no longer about “cookies”, but “user data”.

How the audio is played is interesting:

<div id="embed-container">
  <audio autoplay="autoplay" id="html5Player"></audio>
  <div class="goog-ui-media-flash">
    <embed wmode="window" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" seamlesstabbing="false" allowfullscreen="true" allowscriptaccess="sameDomain" bgcolor="#000000" flashvars="" src="r/musicplayer.swf" class="goog-ui-media-flash-object" name=":0" id=":0" quality="high" style="width: 1px; height: 1px;"></embed>
  </div>
</div>

You’re reading that right. That’s a HTML5 <audio/> tag. First time I’ve seen it appear in a major product. However as of this writing in Firefox, Safari, and Chrome on Mac OS X the Flash player seems to be used. I suspect, but can’t confirm that this may indicate a future intent of using HTML5 <audio/> in place of Flash. Flash is likely the default for now. But it’s still very interesting to see.

The audio itself seems to be 44,100 Hz 320 kb/s MPEG Layer 3 (MP3) audio. The samples I’ve looked at were encoded with LAME 3.98.2. Obviously if they intend to use HTML5 audio they will need to offer something other than MP3 at least for Firefox users. It’s not currently possible to serve everyone without multiple encodings. I don’t see that changing anytime soon.

The servers serving the media seem very similar to YouTube’s delivery servers for H.264 video. It’s progressive download, again just like YouTube. No DRM. I suspect there’s a shared history between this delivery system and YouTube or a very strong influence. But knowing how Google works, there’s likely a shared backend.

It’s pretty good stuff. I highly recommend checking it out. Google built a decent mp3 player in the cloud.

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.

I strongly suspect that even this use case is limited and will experience the same fate as the Flash plugin within the next 24-36 months. HTML5 is supported by browsers, a browser is shipped with the OS and is highly optimized for what it’s running on. It’s also the ultimate in cross-platform. Why write Flash when you can do something for every platform and not rely on a vendor to abstract you?

Platforms like PhoneGap bridge the world of Apps and HTML5 quite nicely. Adobe bought Nitobi which develops PhoneGap, but PhoneGap is also going to Apache Software Foundation which means Adobe’s ability to derail the project would be somewhat limited if they wanted to go that route.

Quite a few Apps use HTML/JS extensively already. HTML5′s success is despite Apple essentially crippling the use of HTML5 in native apps by preventing UIWebView from taking advantage of the Nitro engine. If/when Apple gets to fixing this another barrier will be gone. I suspect Apple will eventually make scrolling that doesn’t suck on iOS easier. Right now Joe Hewitt’s Scrollability is likely your best bet.

Adobe goes on to say:

However, HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. We are excited about this, and will continue our work with key players in the HTML community, including Google, Apple, Microsoft and RIM, to drive HTML5 innovation they can use to advance their mobile browsers.

Interestingly they left out that little browser vendor Mozilla. Perhaps because they are most likely targeting WebKit on mobile and that’s the common tie between those companies sans-Microsoft which they need IE support. If Adobe wants a future here they should learn quick that you can’t ignore platforms. My advice to Adobe is to make sure their solution allows developers to bring their product to any modern browser on any device.

Flash is the last plugin with real usage even on the desktop. This is the first step towards the concept of plugins in the browser going away. It’s unlikely many will see a need to go HTML5 on mobile and develop a separate Flash code base to do the same thing on a desktop. The name of the game these days is write once, run anywhere (credit to Sun for the slogan). Today marks the start of the decline of Flash.

As Brendan Eich best put it: “Always bet on JavasScript“. I have and I continue to do so. The Open Web is winning. Slowly but surely.

For Users

New Look For Tabs

One of the first things that you’ll notice is tabs on top. This paradigm really makes more sense since the tab defines not just the content but the environment it’s viewed (prev/next button, URL bar). It’s also just much sleeker looking. After a few minutes you’ll likely agree this is a better approach than tabs under.

Another nice touch is if you enter a URL that’s already open in another tab, you’ll be given the option to switch to that tab. Perfect for those of us who end up with 50 tabs by lunch time.

It also just feels tighter and less intrusive on the web browsing experience.

App Tabs

App Tabs are a great way to pin sites you use constantly (webmail, Twitter, Facebook, etc.) to your browser and make them easily accessible throughout the day. I suspect many webmail/Facebook addicts will really dig this feature. To use it, right clicking on a tab and “Pin as app tab”. Don’t need it? Don’t use it, it’s not forced upon you.

Tab Groups

Tab groups are simply a way to group your tabs so that you can stay a little more organized through the day. For example you might group tabs for “personal” and “work” then switch between the two groups a few times per day, rather than navigating through 50 tabs to find what you’re looking for. The tab groups interface also gives you a more visual way of navigating tabs and a search feature for searching for a particular tab. I personally like it for searching through the dozen bugzilla bug reports I have open through the day. It takes a little effort to work into your workflow, and I’m personally not quite there yet, but once you do it seems to really be handy. Again you can ignore it if you feel no need.

Goodbye Status Bar

The status bar you used to see at the bottom of the window is gone for most people. If you have an add-on that relies on it, for now it will still show (one of my computers still has it). Just another few pixels for web content. It does take slight getting used to for the technical folks who watch the connections as we’ve been used to looking at that bar for 15 years or so. For the rest of you, it’s just more web on your screen to fill with photos of cats and amusing captions.

Polish

Like every Firefox release, there’s little polish, cleanup, simplifications everywhere. To many to go into each individual tweaks but you’ll see some, and others you correctly won’t see as unused and outdated options are gone.

Sync

Sync is now built-in. Settings, passwords, bookmarks, history, open tabs. It’s encrypted on your computer then sent, so the only one who can view the data is you. I’ve called this the ultimate security model in the past. It’s optional, you don’t have to use it, you don’t loose anything by not using it, other than the ability to sync multiple computers obviously.

Add-on Manager

The add-on manager got some love in 4.0.

OMG Fast!

Firefox 4 is faster in almost every respect. First of all, it seems much more responsive on startup. Its JägerMonkey JavaScript engine has really made a difference in various benchmarks including Kraken, Sunspider, and V8. It also has hardware accelerated graphics. Even on Windows XP, which is still fully supported (ahem).

Out Of Process Plugins (Mac)

Windows and Linux got this in Firefox 3.6, the Mac version was a little behind schedule. Plugins now run outside of the Firefox process. That means when a plugin like Flash crashes, it won’t take out your entire browser. As Windows users will tell you, this makes a big difference in terms of stability.

Do Not Track

Simply put it’s a way to tell websites and advertisers that you don’t want to be tracked. It’s obviously up to websites/advertisers to honor the flag.

To enable it go into Preferences and under the “Advanced” tab select the “General” sub-tab and check the “Tell web sites I do not want to be tracked” checkbox.

For Developers

Support for WebM Video

I’ve discussed WebM on this blog before and won’t repeat what I’ve said before. WebM is an open standard, it looks great.

WebGL

WebGL is amazing. Check out some of the demos by Mozilla or gathered by the Chromium team.

Take a look at Flight of the Navigator and remember: this is the web!

Fix for the CSS :visited hole

Just a FYI, this no longer works.

Web Console

This replaces the old Error Console and in many ways is almost like Firebug Lite. It’s got some great features like HTTP headers and will make it a lot easier to quickly debug things if you’re using a computer without Firebug already installed. If you are a web developer make sure to take a look.

Do Not Track Header

This is a feature that’s been in the news quite a bit, and mentioned above. When enabled all HTTP requests will include the following header:

DNT: 1

HTTP Strict Transport Security

A HTTP header to tell browsers to only use HTTPS to communicate with the site. As more sites start to switch to HTTPS this is a great way to mitigate some potential attack vectors.

CSS border-radius

If you’re a web developer or designer you’ve likely tried to do this before using images and realized how much it sucks. Now you can do it with the simplicity of CSS.

CSS -moz-calc

Do calculations to determine the size and shape of an object. I can’t tell you how many times this would have been realy helpful.

HTML5 Parser

Faster, more powerful, more consistent, futuristic!

Partial Support For HTML5 Forms

Forms in HTML5 are pretty awesome. I won’t go into detail on HTML5 forms here, but you should check them out.

SVG Animation with SMIL

Exactly what the title says. I suspect this will result in some really cool things over time, and some really pointless things that we’ll still find amusing.

Of course that’s not all, just the stuff I really find to be the most interesting.

The Real Deal

Persistent cookies are nothing new. Essentially the strategy works like this: Store data everywhere you can on the users footprint, and if data it deleted in a few locations, you copy it back from another location the next time you can. It’s regenerative by design. A popular example is evercookie which uses:

• Standard HTTP Cookies
• Local Shared Objects (Flash Cookies)
• Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
• Storing cookies in and reading out Web History
• Storing cookies in HTTP ETags
• Internet Explorer userData storage
• HTML5 Session Storage
• HTML5 Local Storage
• HTML5 Global Storage
• HTML5 Database Storage via SQLite

Note that several of these aren’t HTML5 specific. More than one of which isn’t cleared by just “erasing cookies”.

HTML5 does add a few new possibilities, but they are also by design as easy to control, monitor and restrict as your browser (or third-party add-on) will allow. HTML5 storage mechanisms are bound to the host that created them making them easy to search/sift/manage as HTTP cookies. Much worse are some of the more obscure cookie methods (Flash Cookies, various history hacks). They don’t really provide any more of a privacy risk than what the browser already has been offering for the past decade.

To Shut Up The Geolocaiton Conspiracy Theorists

Before someone even attempts the “Geolocation API lets advertisers know my location” myth, lets get this out of the way. The specification explicitly states:

User agents must not send location information to Web sites without the express permission of the user. User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users, as described below. The user interface must include the URI of the document origin [DOCUMENTORIGIN]. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e. beyond the time when the browsing context [BROWSINGCONTEXT] is navigated to another URL) must be revocable and user agents must respect revoked permissions.

Some user agents will have prearranged trust relationships that do not require such user interfaces. For example, while a Web browser will present a user interface when a Web site performs a geolocation request, a VOIP telephone may not present any user interface when using location information to perform an E911 function.

To my knowledge no user agent implements Geolocation without complying with these specifications. None.

No HTML5 Needed For Fingerprinting

Even if you do manage to wipe all the above storage locations, you’re still not untraceable. Browser fingerprinting is the idea that just your system configuration makes you unique enough to be traceable. This includes things like your browser version, platform, flash version, and various other bits of data plugins may additionally leak. The EFF recently did a rather impressive study to learn about the accuracy of this technique. Computers with Flash and Java installed sport 18.8 bits of entropy and result in 94.2% of browsers being unique in the EFF study [cite, pdf]. Of course their data was likely skewing towards more experienced web users who are more likely to have an assortment of customizations to their computer (specific plugins, more variety in web browsers, operating systems, fonts) than the average internet user. I’d wager that their data downplays the effectiveness of this technique.

The idea that HTML5 is a privacy risk is FUD. It doesn’t provide any worse security than anything else already out there. It’s actually easier to counteract than what’s already being used since it’s handled by the browser.

The Future

I still believe all browsers out there can do a much better job of protecting privacy when it comes to local data storage for the purpose of tracking. What I believe what needs to happen is web browsers need to start moving away from the “cookie manager” interfaces that are now a decade+ old and move towards a “my data management” interface that lets users view and delete more than just cookies. It needs to encompass all the storage methods listed above as supported by the browser. Hooks should also exist so that plug-ins that have data storage (like Flash) can also be dealt with using the same UI.

Additionally it needs to be possible to control retention policies per website. For example I should be able to let Google storage persist indefinitely, Facebook for 2 weeks, and Yahoo for the length of my browser session should I wish.

My personal preference would be for a website to denote the longest storage time for any object on a webpage in the UI. Clicking on it would give a breakdown of all hostnames that makeup the page, what they are storing and let the user select their own policy. With 2 clicks I could then control my privacy on a granular level. For example visiting SafePasswd.com would give me a [6] in the UI. Clicking would show me a panel this:

+------------------------------------------------------------------------------+
| My Data Settings for SafePasswd.com:                                         |
|                                                                              |
|  Host                        Longest Requested Lifespan    Your Choice       |
|                                                                              |
| *safepasswd.com              2 years                       [site default]    |
| googleads.g.doubleclick.net  6 years                       [browser session] |
|                                                                              |
|                                                                              |
|                                                       (Done)  (Cancel)       |
+------------------------------------------------------------------------------+

I could then override googleads.g.doubleclick.net to be for the browser session via the drop down if that’s what I wanted. I could optionally forbid it from saving anything if that’s what I wanted. I could optionally click-through for more detail or view the data to help me make my decision. Perhaps this would also be a good place for P3P like data to be available. One of the notable failures of P3P that impeded usage was it was never easy to view so it never caught on.

The browser would then remember I forbid googleads.g.doubleclick.net from storing data beyond my browser session. This would apply to googleads.g.doubleclick.net regardless of what website it was used on.

This model works better than the “click to confirm cookie” model that only a handful of people on earth ever had the patience for. It provides easy access to control and view information with minimal click-throughs.

It also makes a web page much more transparent to an end-user who could then easily see who they are interacting with when they visit one webpage with several ads, widgets, social media integration points etc.

One click to view data policies, two clicks to customize, three to save.

HTML5 is not a risk here. The web moving to HTML5 is like going from the lawless land to a civilized society where structure and order rule.

I’ll start by saying it’s not a bad template. It’s actually quite good and encompasses many best practices as well as incorporates fixes for many common problems (clearfix, pngfix). What I’d like to make note of is that it’s not really bringing you HTML5 and lots of what it does has nothing to do with HTML5.

Not Really HTML5

For starters you’re not really getting HTML5. HTML5 Boilerplate uses JavaScript library called Modernizr. As their website explains:

Modernizr does not add missing functionality to browsers; instead, it detects native availability of features and offers you a way to maintain a fine level of control over your site regardless of a browser’s capabilities.

It also lets you apply styles to the new semantic HTML5 elements like <header/>, <footer/> <section/>.

What don’t you get? Well for starters you’re missing <canvas/> and <video/>. Other than tag elements you’re also missing things like Gelocation, Drag&Drop, web storage, MathML, async attribute on <script/> to name a few. SVG?

Pretty much all the headliners in the HTML5 spec aren’t included. Some like <canvas/> could be helped by way of explorercanvas, but that’s not in there by default.

HTML5 Boilerplate also makes reference to things like Access-Control which still doesn’t work in older browsers. They also suggest setting mimetypes for HTML5 video. This isn’t by any means bad, but hardly makes <video/> useful to everyone. Browsers are still pretty fragmented between webm, ogg, and h.264 (mp4). Then you have older versions that support none of these.

Using gzip on ttf,otf,eot files seems to be a good idea. WOFF however are compressed and correctly excluded.

WTF Does This Have To Do With HTML5?

There are lots of things that I would consider best-practices, but would hardly consider to be HTML5. For example pngfix for IE6, .clearfix, apple-touch-icon, console.log wrapper being the most obvious.

Setting far-future cache times are good, and disabling Etag is a good idea, assuming you rename the file every time it updates. But what does this have to do with HTML5? Is this even practical for everyone?

Then there is some interesting css work like inline print block. There are also a couple of nice usability fixes that I like. Regardless, they are just good design and UX. Not HTML5.

As for the graceful degradation and mobile optimization… that’s design and css. There is no reason why any HTML4 or XHTML site couldn’t do that today. Most choose not to do so in favor of serving different content (including ads) to different devices.

Options -MultiViews… grumble. I’m not particularly fond of it, but again if it works for you, I wouldn’t push you away from it.

Removing www… I hate this one. In my experience the only people who insist upon this have never dealt with websites with high volume and had the requirement of using a CDN by way of a CNAME in front of your site (your domain must be an A record). What is the real benefit here other than some sort of URL ascetics? I’ll let you in on a little secret: The IP address for this blog is hardly maximizing feng shui.

Best Practices != HTML5

Many of these things are best practices. Some of these depend on your application. Most of these aren’t HTML5.

Lets just clarify that HTML5 is not about disabling MultiViews getting rid of the Etag header and being able to style <section/> elements. HTML5 is more than that.

Your ability to use HTML5 still depends on widespread adoption of modern browsers like the latest and upcoming versions of Firefox, Chrome, Safari, Opera, and even IE 9.

Again, HTML5 Boilerplate is not a bad starting point. My point is you’re not really getting as much as it initially sounds like. It’s a bunch of fixes you likely already have in your toolkit already assembled. If that’s helpful: great. But don’t think your missing out on a new era of the Internet by not adopting it. Most good web developers have done these things for a long time now.

First, there’s “Open”.

Steve is right. Flash isn’t really “open”. The iPhone isn’t either by any means. In fact it’s the most restricted computing platform in the world as far as I know. What he did note is that the iPhone uses WebKit and by proxy the web is the most open platform on the planet. That’s very noteworthy.

Second, there’s the “full web”.

Flash video itself isn’t that great by todays standards. That’s why sites like YouTube are serving HD video in H.264 rather than VP6. H.264, VP8 and Theora are the future. If all 3 or just one will survive remains to be seen. Regardless any of them can be played outside of Flash. The dependency on Flash to build a player is going away more and more each day.

Regarding games, this is a silly point. Almost all Flash games need a keyboard or mouse to work. They would never work with a touch screen. Nor would they scale to fit the screen. They would need to be significantly reworked/rewritten.

This is yet more alluding to WebKit and HTML5 where there are solutions already in place.

Third, there’s reliability, security and performance.

It’s pretty hard to dispute the reliability of Flash. It’s by far the driving force behind things like out of process plugins (OOPP) in Firefox among other browsers. It’s also been subject to lots of security vulnerabilities.

Fourth, there’s battery life.

The WSJ quotes Adobe’s Shantanu Narayen as saying the claims of Flash being battery draining are “patently false” but if you look at a CPU monitor while browsing a page with Flash, you can see the load increase quite a bit. Blocking flash on your browser does speed things up and keep your system cooler. I’m very suspect that Adobe has solved this in cell phones when they don’t even seem to have it under control in Windows.

Fifth, there’s Touch.

I already mentioned that mouse/keyboard interfaces just don’t work on the iPhone. No need to rehash that.

Sixth, the most important reason.

That’s actually a vague header. The reason is that they don’t want a third-party sitting between the iPhone API’s and developers. If that happens, developers are limited to what that third-party decides to implement. At the very most developers on the Flash platform get whatever is supported on all Flash platform (greatest common denominator).

That leaves Apple in a stupid position. They could implement killer features in the iPhone and create amazing API’s to take advantage of the features. But if Adobe doesn’t see a way to support things across platforms, or just doesn’t see the cost/benefit of implementing that feature, developers can’t use it. That marginalizes the product for Apple as well as developers.

Conclusion

I found this very interesting that he closed it like this:

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

In February of 2007 Steve Jobs wrote another letter on DRM. It’s noteworthy because in January 2009 Apple launched the ability to buy non-DRM protected music. The letter was really a hint at where things were going. He’s repeating the PR strategy that he used then, make no mistake of it.

I have a feeling the day will come where the App Store is deprecated in favor of promoting HTML5 based Applications either directly off the web or packed similar to how Dashboard Widgets are done now on Mac OS X. The App Store will be around for quite some time, but it will eventually morph.

That is why WebKit is so important to Apple. They want to abstract their OS to the point where they can provide very high level hooks into features they want developers to be able to use. The current iPhone App SDK was a solution created by Apple as a way to let developers put applications on the iPhone as an afterthought. The moderation is so that they can keep their security record intact and could shut down a malicious app before trouble becomes rampant. That puts them in the position where they can either approve all content and be viewed as sleazy by more conservative folks, or they can let everything go and accept that reputation. They obviously made their decision. Developers and some geeks hate it, but 99% of the rest of the world doesn’t even know about the process. Nobody wants to know how sausage is made.

The App Store will likely morph to feature Dashboard Widget like applications (not to different from Palm’s WebOS). Apple will still be able to cash in via that distribution point since they can use DRM giving them the only way to actually sell a protected application. You can view them online via you’re browser.

That’s my prediction. The day will come when the iPhone SDK that we know today will be deprecated. WebKit and HTML5 aren’t there today, but the day will come when they will be the tier 1 development platform for the iPhone. Steve Jobs is just laying the groundwork today.

For desktops, other platforms and browsers it’s worth noting that there’s a lot to gain here.

< !doctype html>

I suspect this might have changed when they launched that new fade effect. I also noticed they are doing so when using the new YouTube “Feather” beta. This shouldn’t be too surprising considering their involvement in the HTML5 specs and developing a web browser and announcing it’s moving away from Google Gears.

Of course the pages don’t validate, and don’t really take advantage of much HTML5 features (that I’ve seen at least). But it’s a step in the right direction. With modern browsers like Firefox, Chrome, Safari becoming more popular it’s slowly becoming a reality.