More failed DOM

20070514418

Remember way back when I mentioned the difficulty of changing a textarea‘s wrap attribute via the DOM because it was actually part of the specification? Well, here’s more difficulty manipulating form elements, this time due to browser not meeting the spec.

Labels are pre2k

Forms always seem to want to be crammed into little spaces not quite fit for labels. Especially login forms. So designers omit labels in favor or using a default value in within the input field. It’s easy enough to clear a field’s value with a few lines of Javascript so no problem there. What about the Password field on login forms though? Is ******** really a good enough label?

I’m quite certain I rather recently saw an article about this using the idea of overlaying text on the input to cover the password field then move it off once the field received focus. I could find it today though. Regardless, I was hoping for a different approach.

Start with a password field in case the user doesn’t have JS. Hopefully the stars/bullets give them enough of a hint as to what the field is for
If JS, onload change the type of the field to text so the word Password shows in the field
onfocuse change the type back to password for entry
onblur, if left blank, change back to text and set value to Password, else leave as type password

Sounds simple enough with a few getAttribute‘s and setAttribute‘s, right?

Rebuild

Here’s IE’s response to setAttribute("type","password"):

Could not get the type property. This command is not supported.

Turns out as of IE5, the type attribute can’t be changed after being created. With that in mind, there are two options left:

Create both fields from the start and show/hide them as needed.
Remove one input and create another as needed.

Since I already had some JS for duplicating/removing elements and I wasn’t fond of having a useless input field on the page, I’m down with #2. Or just using labels they way they were meant to be used.