I remember when the behavior for placeholder=""
text on inputs and textareas made that subtle functionality change in WebKit where the text would remain in place until you started typing rather than disappear on focus of the empty input. I think it may have been first on iOS actually, but now both stable Chrome and Safari do this.
I also remember thinking it was a smart change. Of course the placeholder is no substitute for a real
However, Jeremy Keith points out some research by Markus Earnst that suggests leaving the placeholder in place breaks some expectations and causes problems:
It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible.
Granted, the research was a bit limited in scope, but it makes sense.
Jeremey provides this CSS solution if you want the old behavior back in WebKit based browsers:
[placeholder]:focus::-webkit-input-placeholder {
color: transparent;
}
This is me chiming in with a possible best-of-both worlds middle ground:
[placeholder]:focus::-webkit-input-placeholder {
transition: opacity 0.5s 0.5s ease;
opacity: 0;
}
The second time value in that transition means “wait half a second before firing off this transition.” I suspect that some people click or tab to inputs to get ready to enter information before they are cognitively ready to pay attention to that input yet. But once the focus takes place, then they start paying attention. If we give them a half a second where the placeholder is still visible and another half a second to fade it away, that is likely enough for them to understand the hint that the placeholder was giving them.
The event timeline being:
- User clicks (or taps, or tabs to, or whatever) the input
- Their eyes move to the input and their mind starts paying attention to it
- They comprehend the placeholder hint
- Placeholder goes away
A demo of that and another variation where the placeholder slides away toward the label:
Check out this Pen!
For the record, I’m not saying this is absolutely better. There is no hard science here. I’m just proposing an alternate UI experience that seems to make sense to me.
Are there any other solutions we could explore?
What about a different styling for placeholders when input focused? Like a lighter color maybe. Kind of “hey look, I’m almost gone so you can type, but you can still see me to get tips”.
Quick idea here: http://jsfiddle.net/vbkBk/
Hugo, I guess the real point here is “It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible.” and your idea could still confuse those users.
Hugo, I like that idea. My only concern is that if it’s too light, you are introducing potential accessibility problems. A typical placeholder already has lower-than-average contrast.
Edson, instead of looking at user behavior, let’s try to figure out the reason behind it. I’d be willing to bet they don’t realize the field is active without a clear visual change. Making the text lighter provides that change.
Of course, if the reason is that they think it will leave the old text in there (let’s face it, nobody wants every search string to begin with “search”), this solution still might not work.
Yeah, I’d have to agree with Edson. And in testing, I’ve also seen “type hesitation” behaviour. I’ve even 2nd guessed myself a couple of times, depending on the content that’s in the placeholder and how it is styled.
another option would be to move the placeholder text up:
This way, you’re getting the example out of the way. Not sure of the usability implications, though. Maybe I’ll test it out.
Great! I can’t see a reason to don’t adopt this as a Best Practice.
I can. Mainly, because it is not the best practice. You focused on textfield and your prompt is gone. And no way to get it back without leaving the input (as opposed to deleting whatever you typed-in and placeholder reappearing).
And the very premise is weird. What if I typed a few characters myself? Should I get paralysed by their presence and type no more?
@Rimantas – if you start typing, the placeholder disappears anyway…?
Nice one Hugo !
Regarding the second example where the placeholder is sucked into the cursor (it would be a neat, probably overkill effect to decrease the font-size so that the transition looks as if it were pulling the text into a vacuum …), it would be more usable to shift the placeholder text to the right of the input. This is me just musing:
1. The example doesn’t disappear.
2. You don’t have to worry if the transition is too quick or disorienting.
3. The placeholder appears to “make space” for your entry.
4. The placeholder disappears anyway as soon as text is entered, which should be the indicator that the user is ready rather than time the placeholders disappearance or otherwise infer that the user might be ready before s/he is.
Personally, I like Hugo’s solution best (tho’ I’ve never been a fan of the fuzzy blue outline…)
The first time I used an HTML5 placeholder I thought it was broken. I couldn’t understand why the placeholder wouldn’t disappear when you focused the textbox.
I thought it felt so wrong that I went back to using a jQuery plugin we’d been using for years in older browsers. It still works on all browsers.
How about not fading to full opaque but something like 0.4?
By the way, you can use the placeholder “John Smith” as in your examples, or something like “Enter your full name…”. Is any one of those preferred? Personally I like the latter as it clearly states you need to start typing, which should fix this:
As far as I know, the label answers “what?” and the placeholder answer “how?”.
In this very example, the label should say “Your name” (or whatever comes close) while the placeholder should show how to fill the field (last name + first name ? first name only ? nickname ?), often with an example like “John Smith”. That’s why we use to add “e.g.” in front of the placeholder in many cases.
Please someone corrects me if I make no sense.
I guess you’re right (since it’s called placeholder after all), but I’ve seen a lot of places where they put ‘label stuff’ in the placeholder… and I like it that way too :) Too bad about the browser support.
Anyway the page didn’t refresh properly when I posted this, else I’d have seen my first suggestion was a lot like yours.
By the way, this very page is using placeholders as ‘labels’ (and some polyfill). The labels are there for UX, just not visible.
For me the delay of half a second doesn’t make sense, it feels awkward. I’m really accustomed to the placeholder just disappearing the moment I click into the field. And I think it’s not true that I do need this second to recognize the hint. I read the text before I start moving the cursor. With the placeholder disappearing after 0.5sec I get confused because the placeholder which is not as much as a label is getting to much attention, interrupting my own ‘timing’: read – think – write. It might be distracting.
No one seems to have noticed, but in Firefox the behavior of the placeholder attribute is to leave the text until the user begins typing, at least in the most recent versions. Webkit solutions (or should I say -webkit solutions) to Webkit problems don’t seem to last long these days.
Confirmed. Sigh.
::-moz-placeholder
can probably be used for the same effect (untested).*&^#& wrong link (lol, don’t ask why I had that URL on my clipboard)
edit please?
correct link:
::-moz-placeholder
(https://developer.mozilla.org/en-US/docs/CSS/:-moz-placeholder)I’m sorry, I know this is really feeding the off-topic-ness here, but that mistaken link that traq included is the FUNNIEST thing I’ve ever read…
LOL!
It’s good to see research funding in the U.S. is going into really important issues! :D
From my testing a few minutes ago, using ::-moz-placeholder and the transitioning opacity makes the placeholder text vanish when you focus on the input field, but it vanishes immediately instead of transitioning.
Here’s an alternative CSS transition solution, that allows you to keep the placeholder text visible while removing it from the input field. The layout would need to be tweaked to accommodate your form layout, I’d suggest, pushing it below the input field for stacked form layouts.
It only works in Webkit, mind you, but I’m okay with progressive enhancement. It would be fairly simple to duplicate with Javascript, anyway.
Neat solution, but I think people rely a bit too much on placeholders these days and ignore labels. As long as you’re not asking for something weird, most people will understand a label like “Email” or “First Name”. Placeholders have their… uh.. place, but honestly in my own opinion, should go away immediately when you focus. From an accessibility standpoint, labels have been the way to go from day one, and still are. shrug
Agreed. Placeholders should support labels.
I don’t have much of a preference anymore. When I first saw that it didn’t go away immediately I felt confused like it was poor coding or something but once I started typing it made sense. I think people are trained from years of filling out forms that the placeholder should go away when focused on.
The company I work for definitely doesn’t like the new functionality and always has me make it disappear on focus. I’ve always done that with jQuery before but I’ll definitely be using this method from now on.
A lot of things don’t make sense to users at first, but they learn eventually. Maybe this is a case where the added functionality is worth the trade-off of a small retraining period for users?
We also need to keep in mind that many different patterns (some good and some bad) might end up being more confusing overall than a single mediocre pattern…
That’s one of the main issues here, I think: people get used to habbits (too) quickly, but don’t/can’t change them easily afterwards. They tend to hold on to their old conventions. Maybe it’s only a matter of time before they adapt and accept this.
It’s a fine line between usability (designer’s side) and expectation (user’s side). Getting these two in line cannot be done by the designer alone.
In basic UX testing around the office, I have had a couple people mention the exact same issue with placeholder text. Saying that they didn’t realize what it was or that they could begin typing. My preferences is, rather than removing the placeholder completely on :focus, to dim it out much further. Keep it readable, in case they are just blindly tabbing through the form, but make it clear that is responded to their actions. I am not sure if this is any better, but I hesitate to completely hide the text.
A lot of people seem to be using placeholders these days, and I think the end user is probably getting used to them. I think people are probably used to there browser defaults, and changing them could just cause more confusion. Im not saying the way browsers do it is right, but it’s probably just what the user is used to, so I think in this case it might be best to keep it.
I wonder it this is a question of browser vendors responding to widespread hacks / misuse of the HTML5 placeholder.
We have forms with labels which are accessible and valid, then placeholders come along and look nice from a design point of view. So then designers/developers think ah ha we could dispense with the label and save a handy bit of space for our mobile phone view to boot.
But now there is a problem – no label once the user focuses causing confusion and abandoned forms. So devs start using hacks to keep the placeholder in view on focus.
Responding to this -webkit to the rescue with place holders remaining visible until the user starts to type – at this point they know what they are typing and no longer require the label.
-moz then follows this pattern.
Now there is a new problem – confusion / cognitive load placed on the user when faced with place holders acting as quasi labels remaining in the way when they want to type. (I have seen people struggle with this when filling in forms – believing they have to delete or select and overtype the placeholder – users worry they will “break” forms or accidentally submit incorrect information.
It seems the best solution is to go back to using labels as labels and placeholders as placeholders which disappear on focus.
That said I wonder if the browser vendors have solid research to say placeholders staying in place is a better user experience, in my experience it is not.
I think adding a fade or delay then fade or change of colour (elegant though they first appear) will only add to the confusion as it adds a further pattern which users aren’t used to.
If the research is right, and people are getting confused because the placeholder text doesn’t disappear, then I would just remove the placeholder text altogether upon :focus.
It’s best practice to accompany the form fields with labels, and therefore the placeholders are just a kind of ‘nice-to-have’ prompt/example for the user. If they get confused as to what they’re filling in when the placeholder disappears, then the labels aren’t doing their job properly.
How many times have you filled in a form with ‘Name’, ‘Email’, etc and not understand what kind of data you need to be giving? Obviously an example placeholder gives you a good idea as to how much of a name you need to give (‘John’, ‘John D’, ‘John Doe’), but most of the time, I can’t see it as a necessity.
If, like this form I’m writing in now, the placeholders are used instead of labels, then obviously they become a pretty important aspect of the form. I saw a decent example not long ago where the placeholder moved to the top right of the field, in a smaller font, when the field gained focus. For me, this worked really well, I still knew what the fields needed when I was tabbing through, but the primary focus was on what I was inputting. I can’t remember where I saw it, but here’s a quick example: http://cl.ly/image/1F0l2j1B3X2Z.
And what about the users that click/tap on the Search button without entering anything in the field thinking that the *placeholder/hint is actually what they’re searching for?
And what about the users that actually click/tap on the Search button when the field is totally blank?
Yes, I’ve had to deal with these analytics about 4-5 years ago, I was amazed at how… dumb some users are**.
Long story short, for the first example we had “Type your term here” as placeholder via JavaScript (*yeah, yeah, I know, wrong use of the placeholder concept, but that wasn’t the reason why we saw such behaviors) and the most searched term in our analytics was? Yes, “Type your term here“.
So we removed the hint/label, and the most searched term was?… “(blank)“.
Seriously, WTF.
I know now that no matter what the Gods of Web Design, Usability and JavaScript do with this
placeholder
tag, there will always be users that will get confused by one solution AND the other.**I’ve done my fair share of stupidities as well, and still do ><
Young people ok, but thinking about eldery users…
I bet those people would try delete the placeholder before starting to type…
the fade-off thing look a nice solution
–sorry about my english grammar–
I’ve not seen a solution for having this work in IE7, IE8 or IE9 even. If there is one, please let me know. Otherwise, this fallback will work on all browsers all the time.
input value=”YOUR TEXT HERE” onfocus=”if(this.value==this.defaultValue)this.value=”” onblur=”if(this.value==”)this.value=this.defaultValue”/
Text will display across all browsers, and when the user clicks, the text will disappear. There is no smooth fading out, but this is bulletproof for me.
Guys, have you tested this peice of code on Mozilla.??? cz it does’nt work in Mozilla for me…
Any suggestions for this to work in Mozilla would be awesome..
The reason it does not work in FF is because it prefixed with -webkit-input-placeholder.
see this answer
One way we got through the issue was to make the placeholder text look different from text by putting it inside <>
Very interesting, all the way around. If nothing else, if you tend to be fascinated by people, the deeper you dive into this stuff, the more you realize how many ways there are to perceive any one thing.
Regarding suggestions here, all of which are worth considering, both in the article itself and the comments, like so many things, it’s a constantly moving target.
As of April 4, 2014, the embedded examples don’t work as stated (in the article or comments) in Safari 5.1.10 or FF 28 on Mac 10.6.8, but does in Chrome 33.0.1750.152.
Not only browser, but browser / OS specific. But that’s another subject.
Anyway, I could’ve missed something in the explanations and discussion; I am admittedly a total noob compared, I suspect, to every one else who commented here.
I think the float labels pattern is the most elegant, but I suppose this might entice users to begin typing. Not only does the text pulse, begging for some interaction, but I’ve used the word ‘Type’. Unless they can’t read, I don’t know how it could be any clearer.
I spent 15 minutes signing up at CodePen and trying to figure out how to embed the forked pen that I just linked to. The code that I was supposed to copy and paste looked like just a link, which is not what I wanted. I found some slightly-helpful info over on the CodePen blog, which led me to believe that you just paste in the code, and the script replaces the link, so to speak with the embedded code. I tested this out successfully on my home server. So I do just that here and click ‘Submit Comment’, only to see the link and not the embedded pen. Oy vey.
Hey James,
Sorry you had so much trouble with the embed. The problem you dealt with is that you were trying to use the full HTML embed code here in this comment thread. Totally understandable you would think that’s possible since HTML is supported here. The issue is that our embed code uses a
<script>
, as you saw. I don’t (and pretty much no sites) allow you to post arbitrary scripts in comments. That would be a major security vulnerability.To get around that, at CodePen we offer oEmbed so you can just drop a link in the URL and it’ll do an embed.
We’ll try and make the docs more clear.
I’m using some adaptation for this and was wondering if there any way to do the reverse transition? ie fade back in if the user clicks out without typing anything. My case is here: http://codepen.io/SimeonC/pen/wsDaH (just focus then blur the field).
Nevermind – It helps if add the transition NOT on the class you’re adding and removing.