"Stupid users foiled again!" [placeholder attributes]

[Stomme poes]

Some may laugh at the description of problems some of these users have experienced, but honestly, who cares if they really were dumber than a bunch of rocks? We're not professors grading them. We're trying to get them to just use our stuff without frustration. If dumb people can't use our sites, we have failed. Even if your target audience is rocket surgeons. No, actually especially if they are.

http://lists.w3.org/Archives/Public/...3Mar/0193.html

It appears years of Javascripted placeholders has trained most of us (including me) to expect the temporary text will vanish the moment the input receives focus. This despite the fact that this is a sucky way of doing it: going through a form, many users (including me) hit tab right away to finish the previous field, before our eyes have gone looking for the next label.

So most browsers (not Opera I notice, but Firefox has switched) are currently showing the HTML5 placeholder attribute the way webkit first did: the placeholder remains until the user actually tries to type something. While this is really a better way to do placeholders, the above mail shows it's still a problem for users, who've been trained to try to remove placeholder text if it does not vanish once focus is on the input.

So, interesting to hear these anecdotes regarding placeholders. Anyone have any good usability stories out there?

[Rubble]

I can not see the point in having a lable "Name" next to a text box and then having "Enter your name" or something similar in the box in the first place.

I quite often start typing and find my text in the middle of a placeholder text

[Mat30]

Yes, rubble is quite right. With the JS method being so common, I sometimes find myself getting no search results for "Search this sitemykeyword" because developers ignore the principle that whatever is removed by JS should have been added by JS. At least the HTML5 method avoids this kind of problem.

Regarding poes's comment, Mozilla and Chrome annoyed me (with my user's hat on) when they decided that the attribute value should stay visible until you type. It does indeed feel very like being presented with a JS placeholder instead.

On the rare occasion of using a placeholder in lieu of keeping the label on-screen, I add something like this:

input::-moz-placeholder {color: #222; opacity: 1;}
input:focus::-moz-placeholder {color: #888;}

This fades on focus, then disappears when typing, which I like. Colours are just examples. Webkit code is much the same, but without opacity. The opacity is necessary to override the colour in Firefox (which is dumb). And speaking of dumb, why did Mozilla omit backward compatibility when switching from pseudo-class to pseudo-element syntax recently? I bet that a lot of placeholder colours remain broken because of this, and the default colour is far too pale.

[ralph.m]

I occasionally use Safari, and there is default text in the search bar that says "Search Google or enter an address". That text only disappears once you start to type. I have to admit, I find it very unnerving to have text there once I've focussed on that field. I would always prefer to have a label and no default text in the input field.

[Mat30]

That's sort of a weird disconnect in one app's UI, Ralph. I believe that Safari still uses the "old way" of styling placeholder attributes (can't check right now), so it has one behaviour occurring in the browser chrome and another in websites. I wonder if Safari will start to use Google/Mozilla's "new way". It would be wrong, but it would not surprise me.

[ralph.m]

so it has one behaviour occurring in the browser chrome and another in websites.

Yes, a bit odd. I find it unnerving because it always makes me feel like I haven't actually focused on the address bar when I have. I guess I've gotten used to the text disappearing on focus. As mentioned above, it's doubly annoying when the default text doesn't clear and gets mixed with what you actually typed. That's got to be the worst scenario of all.