Forms will be able to require the user-agent to do pre-submission validation. Obviously we can’t rely on this for security reasons, but it will save us from writing JavaScript validation scripts and give users a better experience with our forms.

And the validation is fairly robust. <input/> elements gain an attribute called pattern, which accepts a simple regular expression, like "[A-E][0-9]{7}".

But you probably won’t need the pattern attribute very often, since there is a whole slew of new types that the UA will be expected to provide controls for, and validate. Crucial types, like email and url, and difficult types like datetime-local and color.

jQuery UI is great, but it doesn’t compare to this kind of power.

I only realized the sorry state of our current form controls very recently, after getting an iPhone. Built-in form fields on the iPhone can trigger different input methods. A field, like ZIP code, that accepts only numbers, opens the keyboard to the numbers first. A field that wants a URL can open a keyboard with a .com button to save time. But web pages can’t do this. They can only say that an input accepts arbitrary text.

For mobile or touch-enabled UAs, knowing that you can open a keypad instead of a full keyboard is a great step forward. For everyone, having date and color pickers built into the UA means saving both developers’ and users’ time. Less time to build and less time to download, consistent experience in the UA across web sites.

Forms also get a new event, input, which is a little like the current change event, except you don’t need to wait for the element to lose focus for the event to fire. That’s just useful.

Controls get new methods, stepUp() and stepDown(), to enable, for example, very fast forward/backward selection on a date input.

The last fun addition I’ll mention (go read the links, they’re all to the same page) is the autocomplete attribute. It doesn’t do what you hope it does. What it does is specify to the UA that it should not remember and suggest values for this input. It lets the UX designer decide whether to use Firefox or IE’s built-in autocomplete on a per-field basis. Useful. (Not as useful as, say, an autocompleteUrl attribute that could load some JSON or XML, but still useful.)

Building forms is going to be so, so much better once these are widely support.

I just downloaded the Spore Creature Creator, and this file showed up on my desktop: 792248d6ad421d577132c2b648bbed45_scc_trial_na.exe.

Why not “Spore Creature Creator Trial Install.exe”, or, if spaces aren’t your thing, “SporeCreatureCreatorTrialInstall.exe”? Either would be infinitely more meaningful than an MD5 hash followed by an acronym and a region code.

While the developers may have had a reason (though I can’t imagine it’s a good enough reason) to use this file name, the web team has no excuse.

There’s a lesson here: be nice to users. Whether it’s just a file name or helpful error messages or designing a user interface/experience, don’t treat your users like machines that parse your (bizarre) internal formats.

And Will Wright, if you’re listening, ask someone to rename that file.