HTML5 One Time Submit

One of HTML5’s coolest features in my opinion is that forms are easier to build. Things like required, autocomplete, pattern make it much easier to create an intuitive form without having to jump through hoops and repeating efforts to do some basic form validation.

The one thing that I still see as missing is a one-time submit button. Many sites create transactions that should only be performed once. For example, when you click “place order”, you definitely don’t want your transaction being processed multiple times, so what websites do is disable the button after the first click. I’m not sure why, but this little pattern never quite made it into HTML5. I’d love to see something like this:

<input type="submit" id="process_order" transactionsafe="true"/>

Then when the submit button is pressed, it automatically sets the disabled attribute. Either on the server side (if you submit the entire page), or via JS (for a refresh-less UX) you could unset the disabled property should you want the user to be able to submit again (for example if the order failed).

It’s trivial, but we seem to use this pattern quite a bit. It would be nice to one day be able to do this without an event.

Make Login Pages Autofocus

I see this way too often and it gets on my nerves. If you have a page that’s main purpose is a form, such as a login page, please make the page autofocus to the first field in the form. Having to tab or click on the first field is a nuisance. Even big sites make this mistake.

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 😉 .

Common Application Bugs

There’s a curious article in the NY Times about the Common Application‘s technical glitches. The Common Application is a uniform way of filling out one application to apply to many colleges, as opposed to filling out an application for each individual college.

As a web developer, this struck me as particularly odd:

As it turns out, applicants do not have, say, 150 words to discuss their most meaningful extracurricular activities; they have something closer to 1,000 characters (Max said he eventually figured this out). And because some letters may take up more space than others, one applicant’s 145-word essay may be too long, while another’s 157-word response may come up short, Mr. Killion said.

“A capital W takes up 10 times the space of a period,” he said. “If a student writes 163 characters that include lots of Ws and m’s and g’s and capital letters, their 163 characters are going to take many more inches of space than someone who uses lots of I’s and commas and periods and spaces.”

Asked why the problem had not been fixed, Mr. Killion said, “Believe me, if there’s a way to do it, we’d do it. Maybe there’s a way out there we don’t know about.”

Sounds like the folks behind the common application need to go back to middle school and learn about variable width and fixed width fonts. If they had switched to fixed width fonts in the <textarea/> and used the same number of cols and font size it should be pretty accurate. I’m guessing some designer insisted on Helvetica or whatever they are using.

That said, are they actually printing these things out? Is there no way to do this electronically in 2010?

Back in my day (2002), I was advised to go the paper route since many still felt/feared that electronic applications weren’t being fairly considered (and in some cases not processed correctly). That was also the first year public colleges could join the Common Application as I recall. I suspect I was the last class where the majority did it on paper. I guess it’s still an improvement for a technophobic educational system.

Midas in forms

I’m working on a new Content Management system for MacVillage.net. To enhance it’s capabilities, I am turning to Midas.

A perfect time to give a little edge to Mozilla users 🙂

I’ve been looking into this some info a bit. Sadly, there isn’t a ton of good documentation on it for a webmaster right now.

I have a basic HTML form right now. Can anyone provide some insight on how one could take a regular form (such as this forum here), and implement midas, so that the value sent to the server is the rich goodness of midas?

I’m pretty pretty much looking for a drop replacement for a text field in a HTML form. Note there should be a fallback to an equivalent, or plain text field for any browser that doesn’t support Midas.

Comments or Email is of course open.

I think this will be a nice reason for people to use Mozilla.