Shifted Bits Blog

For the background as to why I’m writing what you’re about to read, please read this blog post. For those who don’t want to read it, the short version is that the current implementations input text placeholders, per the HTML5 spec, isn’t as good as a (slightly) different implementation via Apple’s iOS. The post has some code that implements them the iOS way instead of the normal way. The upcoming rant is not about this new implementation. It’s about the comments to this idea, and the general feeling and understanding (or lackthereof) of placeholders in the first place.

The Short Rebuttal

When a web developer/designer foregos the use of labels in support of using placeholders instead, they’re being dumb. And wrong. And a bunch of other things I won’t list, but do follow the same general pattern.

Some History

The placeholder attribute was “created” many many moons (ok, so a few years) ago by people who were concerned about how a user interface looks without a lot of space available. The general idea behind it was to remove the need for labels around an input box to allow for a more compact and minimalistic experience. The tech behind this idea said, effectively: Put the label inside the text element, instead of around it. Then when a user clicks on the input box, the text clears so that it’s ready for user input. That way users still know what’s being asked of them, and are then allowed to provide input when ready. The great irony to this is that the best market that would benefit from this kind of technology (the mobile market), doesn’t implement it natively.

After a few years with implementing this tech in HTML4/XHTML1 and Javascript (and CSS for those who wanted special stylings for this new fandangled placeholder thingymabob), the W3C HTML5 committee added the placeholder attribute to the HTML5 specifications. This would soon be adopted by all major browsers, and backwards compatibility support for older browsers was soon built into most major Javascript libraries (such as jQuery, as a plugin).

The Problem

As I read through the comments on that blog post, I was struck by a seeming dogma-like attitude that placeholders are replacements for input labels. Whether that’s actually there or not is up for debate, but we’ll move on to my actual rant in the mean time.

I do not, and will not claim to be a master in knowledge of the HTML5 spec, nor in UI Design (as that’s more a taste thing that varies human by human), but I will claim to know how to freaking read. The HTML5 spec clearly states that placeholder attributes are not meant to replace input labels. Now, this would seem to be counter-intuitive to the originally designed purpose of placeholders to save screen space. So what happened?

It seems to me that a lot of designers see the HTML5 spec like Christians see the Bible. There are parts of it they like, parts of it they don’t, and will choose to ignore the parts they don’t (or at least acknowledge them being there, and just not practice the parts they disagree with). That’s where problem number 1 arises.

The HTML5 spec is not a ‘bible’

It’s a specification. In any real-world work scenario, if you don’t follow specifications to the ‘T’, as it were, then you would get ready to eat a lot of shit from your co-workers and management because that means the customer didn’t get the functionality or look that they wanted. It’s not your job to tell the customers they’re wrong, it’s your job to make them figure out that they’re wrong on their own terms (this is usually done by charging a lot more for people asking you to do stupid things such as use iFrames instead of Ajax or somesuch. It’s not that you won’t implement iFrames, it’s just that the maintenance for them is so high that you have to make it worth your while).

In the case of web development (and in some aspects, web design as well), the customer is giving you two specs, one explicit, one implicit. The explicit one are the design specs that they give you. They want a logo this color, they want headers in this font, they want a background with this design, etc. The implicit one is the HTML5 specification. The customer may not realize it, but as a web developer/designer it is your duty to implement their spec following as closely as possible to the HTML5 specification. The benefit of that is that (in general practice now, thankfully), properly implemented HTML is rendered nearly the same cross browser. This isn’t to say there aren’t tweaks to be made per browser, but by following the HTML5 spec you’re doing yourself (or whomever is implementing your design) a big favour in keeping the implementation as standard as possible, and therefore allowing for less problems in cross-browser compatibility.

This is where problem number 2 arises:

You’re forgetting something

The fanciest design and the coolest graphics won’t save you from dumb (rednecks), slow (elderly or mentally-disabled), or handicapped (blind, and other disabled) people from visiting your site. Forgetting to have labels for your input tags is nothing more than plain negligence. I will quote a comment (#5, to be specific) from the above-linked blog to prove my point:

I have actually found myself tabbing to another input & back to see the placeholder again, so I also like this implementation.

This also implies something else: That people don’t read what they see on a web page, they scan, and in doing so miss some details. This is a perfect case for why we should not forego the use of label tags around input (which it seems a lot of people do now), but instead use them as they were originally meant to be used: to tell people what to put into a specific input field. That way screen-readers and other slow (and optionally, fast) people don’t get confused about what’s being required.

Remember, the best thing to aim for is the simplest thing you can get. By this I don’t mean simplest to implement, as you can refactor code in any number of ways to keep it simple and easy, but to keep the user’s job simple and clear. I’ll emphasize this with a story.

I was contracted to build a website at the turn of the year. It was a private website only to be used by a small handful of people so it didn’t need to be flashy or anything like that, just able to get the job done. I will admit that when I first built the account creation layout for the website, I used placeholders instead of labels. I found out that this was the wrong way to go about that, when someone used a security key that was given to them for unique identification in the system as their username. Needless to say, that wasn’t exactly how it was supposed to be used. I was astounded at this fact. I thought to myself: “This can’t be possible! It said ‘Username goes here’ very… clear…ly… … … Crap.”

I visited the page, and thought to myself: as someone who doesn’t know what to expect from this site, what does this page tell me? I realized, it didn’t tell me very much. It gave me a few text boxes, whose text would disappear when I clicked on them, and in general it was fairly hard to figure out what was going where and why.

Then I put in labels for the form fields.

The difference was amazing. I showed the old page to a friend who had never seen the site before (they knew I had been working on it, but that was about it), and I asked them to tell me what they saw when the page first loaded: it wasn’t much. They said “well the password goes there, and something called the ‘security-key’ goes there,” and then came the dreaded question, “but what goes in that first one again?”

“I’ll show you,” I responded.

I sent them a link to the fixed web page (you can consider this hallway A/B testing if you want to put technical terms to it), and said “What about now?” They said the difference was simple and clear. It was easy to tell what went were, and if they clicked on an input then it was significantly harder to forget what was supposed to go in there as the text explaining this never went away.

Conclusion

I will forgive the blog writer for his code which doesn’t include labels, as while writing code for blogs you do cut corners because it’s more used to show an idea instead of being proper in every aspect. Also, his demo of the implementation uses labels so it’s ok. He also mentions in comment #16 (in response to #15) that the use of labels and placeholders are not mutually exclusive.

But for everyone else who thinks that using placeholders instead of labels is a good thing: Shame on you. You should know better. We’re not out here to make the web pretty, we’re here to make the web better. Now lets get to it, shall we?