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.

For the intents and purposes below assume the following HTML:

<p>
<label for="checkbox1">Checkbox 1</label>
<input type="checkbox" id="checkbox1" checked="checked"/>
</p>

<p>
<label for="checkbox2">Checkbox 2</label>
<input type="checkbox" id="checkbox2"/>
</p>

You wouldn’t really expect it, but both of these return “on” when you get the val():

$('#checkbox1').val(); // returns "on"
$('#checkbox2').val(); // returns "on"

Now say you flipped them by unchecking checkbox1 and checking checkbox2. Same thing:

$('#checkbox1').val(); // returns "on"
$('#checkbox2').val(); // returns "on"

Now reload the page, so one is checked and two is not checked. Try again this time using .attr('checked');. That also doesn’t work, but that makes sense. jQuery 1.6′s release notes even explain it:

Before jQuery 1.6, .attr(“checked”) returned the Boolean property value (true) but as of jQuery 1.6 it returns the actual value of the attribute (an empty string), which doesn’t change when the user clicks the checkbox to change its state

The best way I’ve found to get a checkbox value is to use the is() method:

$('#checkbox1').is(':checked') // returns true

As to why val() doesn’t check the type of node and do this for me automatically? I’m not entirely sure. I’m assuming backwards compatibility. I suspect I’m not the only one who keeps forgetting this little caveat.

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.

I’m still looking at it myself, but my first impression is that the point of another language is buried in the details of the announcement. This particular sentence I think is the focal point (emphasis mine):

• Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution.

I suspect the real goal behind Dart is to unify the stack as much as possible. Web Development today is one of the most convoluted things you can do in Computer Science. Think about just the technologies/languages you are going to deal with to create a “typical” application:

• SQL
• Server Side Language
• HTML
• CSS
• JavaScript

That’s actually a very simple stack and almost academic in nature. “In real life” Most stacks are even more complicated, especially when dealing with big data. Most professions deal with a handful of technologies. Web Development deals with whatever is at hand. I’m not even getting into supporting multiple versions of multiple browsers on multiple OS’s.

Google even said in a leaked internal memo:

- Front-end Server — Dash will be designed as a language that can be used server-side for things up to the size of Google-scale Front Ends. This will allow large scale applications to unify on a single language for client and front end code.

Additionally:

What happened to Joy?
The Joy templating and MVC systems are higher-level frameworks that will be built on top of Dash.

By using one language you’d reduce what a developer needs to know and specialize in to build an application. This means higher productivity and more innovation and less knowledge overhead.

This wouldn’t be the first attempt at this either for Google. GWT is another Google effort to let developers write Java that’s transformed into JavaScript. This however doesn’t always work well and has limitations.

The web community has actually been working on this in the other direction via node.js which instead takes JS and puts it on the server side, rather than inventing a language that seems almost server side and wanting to put it in the browser.

Google still seems to have plans for Go:

What about Go?
Go is a very promising systems-programming language in the vein of C++. We fully hope and expect that Go becomes the standard back-end language at Google over the next few years. Dash is focused on client (and eventually Front-end server development). The needs there are different (flexibility vs. stability) and therefore a different programming language is warranted.

It seems like Go would be used where C++ or other high performance compiled languages are used today and Dart would be used for higher level front-end application servers as well as the client side, either directly or through a compiler which would turn it into JavaScript.

Would other browsers (Safari, Firefox, IE) consider adopting it? I’m unsure. Safari would likely have a lead as the memo states “Harmony will be implemented in V8 and JSC (Safari) simultaneously to avoid a WebKit compatibility gap”. Presumably IE and Firefox would be on their own to implement or adapt that work.

New languages rarely succeed in adoption. On the internet the barrier is even higher.

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 Ultimate Security Model

I consider Mozilla Sync (formerly known as “Weave”) to have the ultimate security model. As a brief background, Mozilla Sync is a service that synchronizes your bookmarks, browsing history, etc. between computers using “the cloud”. Obviously this has privacy implications. The solution basically works as follows:

1. Your data is created on your computer (obviously).
2. Your data is encrypted on your computer.
3. Your data is transmitted securely to servers in an encrypted state.
4. Your data is retrieved and decrypted on your computer.

The only one who can ever decrypt your data is you. It’s the ultimate security model. The data on the server is encrypted and the server has no way to decrypt it. A typical web service works like this:

1. Your data is created on your computer.
2. Your data is transmitted securely to servers.
3. Your data is transmitted securely back to you.

The whole time it’s on the remote servers, it could in theory be retrieved by criminals, nosy sysadmins, governments, etc. There are times when you want a server to read your data to do something useful, but there are times where it shouldn’t.

The Rise Of Cloud Data And HTML5

It’s no secret that more people are moving more of their data in to what sales people call “the cloud” (Gmail, Dropbox, Remember The Milk, etc). More and more of people’s data is out there in this maze of computers. I don’t need to dwell too much about the issues raised by personal data being stored in places where 4th amendment rights aren’t exactly clear in the US and may not exist in other locales. It’s been written about enough in the industry.

Additionally newer features like Web Storage allow for 5-10 MB of storage on the client side for data, often used for “offline” versions of a site. This is really handy but makes any computer or cell phone used a potentially treasure trove of data if that’s not correctly purged or protected. I expect that 5-10 MB barrier to rise over time just like disk cache. Even my cell phone can likely afford more than 5-10 MB. My digital camera can hold 16 GB in a card a little larger than my fingernail. Local storage is already pretty cheap these days, and will likely only get cheaper.

Mobile phones are hardly immune from all this as they feature increasingly robust browsers capable of all sorts of HTML5 magic. The rise of mobile “apps” is powered largely by the offline abilities and storage functionality. Web Storage facilitates this in many ways but doesn’t provide any inherent security.

Again, I don’t need to dwell here, but people are leaving increasingly sensitive data on devices they use, and services they use. SSL protects them while data is moving over the wire, but does nothing for them once data gets to either end. The time spent over the wire is measured in milliseconds, the time spent at either end can be measured in years.

Enter JS Crypto

My proposal is that there’s a need for native JS Cryptography implementing several popular algorithms like AES, Serpent, Twofish, MD5 (I know it’s busted, but still could be handy for legacy reasons), SHA-256 and expanding as cryptography matures. By doing so, the front end logic can easily and quickly encrypt data before storing or sending.

For example to protect Web Storage before actually saving to globalStorage:

globalStorage['mybank.com'].lastBalance = "0.50"; 

globalStorage['mybank.com'].lastBalance = Crypto.AES.encrypt("0.50", password); 

Using xmlHttpRequest or POST/GET one could send encrypted payloads directly to the server over http or https rather than send raw data to the server. This greatly facilitates the Mozilla Sync model of data security.

This can also be an interesting way to transmit select data in a secure manner while serving the rest of a site over http using xmlHttpRequest by just wrapping the data in crypto (that assumes a shared key).

I’m sure there are other uses that I haven’t even thought of.

Performance

JS libraries like Crypto-JS are pretty cool, but they aren’t ideal. We need something as fast and powerful as we can get. Like I said earlier, mobile is a big deal here and mobile has performance and power issues. Intel and AMD now have AES Native Instructions (AES NI) for their desktop chips. I suspect mobile chips who don’t have this will eventually do so. I don’t think any amount of JS optimization will get that far performance wise. We’re talking 5-10 MB of client side data today, and that will only grow. We’re not even talking about encrypting data before remote storage (which in theory can break the 10MB limit).

Furthermore, most browsers already have a Swiss Army knife of crypto support already, just not exposed via JS in a nice friendly API. I don’t think any are currently using AES NI when available, though that’s a pretty new feature and I’m sure in time someone will investigate that.

Providing a cryptography API would be a great way to encourage websites to up the security model in an HTML5 world.

Wait a second…

Shouldn’t browsers just encrypt Web Storage, or let OS vendors turn on Full Disk Encryption (FDE)?

Sure, both are great, but web apps should be in control of their own security model regardless of what the terminal is doing. Even if they are encrypted, that doesn’t provide a great security model if the browser has one security model in place for Web Storage and the site has its own authentication system.

Don’t JS Libraries already exist, and isn’t JS getting the point of almost being native?

True, libraries do exist, and JS is getting amazingly fast to the point of threatening native code. However crypto is now being hardware accelerated. It’s also something that can be grossly simplified by getting rid of libraries. I view JS crypto libraries the way I view ExplorerCanvas. Great, but I’d prefer a native implementation for its performance. These libraries do still have a place bridging support for browsers that don’t have native support in the form of a shim.

But if data is encrypted before sending to a server, the server can’t do anything with it

That’s the point! This isn’t ideal in all cases for example you can’t encrypt photos you intend to share on Facebook or Flickr, but a DropBox like service may be an ideal candidate for encryption.

What about export laws?

What about them? Browsers have been shipping cryptography for years. This is just exposing cryptography so web developers can better take advantage and secure user data. If anything JS crypto implementations likely create a bigger legal issue regarding “exporting” cryptography for web developers.

Your crazy!

Perhaps. To quote Apple’s Think Different Campaign

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes.

The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them.

About the only thing you can’t do is ignore them. Because they change things. They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward.

Maybe they have to be crazy.

How else can you stare at an empty canvas and see a work of art? Or sit in silence and hear a song that’s never been written? Or gaze at a red planet and see a laboratory on wheels?

While some see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.

Time to enable the crazy ones to do things in a more secure way.

Updated: Changed key to password to better reflect likely implementation in the psudocode.

What makes them so brilliant is that they are actually 100% true. I spent a summer cleaning up just this type of stuff. It’s true, it’s out there, it’s painful.

Quick Hack

Here’s a literally 2 minute hack for the Google Pac-Man tribute on the homepage right now to put your own face on Pac-Man (pardon my poor photoshopping):

To try it add the following bookmarklet to your browser by dragging the link below to your bookmark bar:
raccettura-ize pacman

Now go to Google and press “Insert Coin” to play the game. Once the game loads, run the bookmarklet by clicking on it.

Hack yourself into Pac-Man

Want to make your own? You likely have better photoshop skills than me. Download this image and replace the Pac-Man (and optionally Ms. Pac-Man) images with ones of your own keeping the position and sizes the same. Save as a PNG with transparency. Then upload somewhere. Now make a bookmarklet that looks like this (replacing URL_TO_YOUR_IMAGE with the url of your image):

javascript:(function(){document.getElementById('actor0').style['backgroundImage']="url('URL_TO_YOUR_IMAGE')";})()

Now share with your friends.

Permanent Home

Google has now removed Pac-Man from the homepage but it can still be found here.

Edit [5/24/2010 @ 8:45 PM EST]: Added “Permanent Home”.