The placeholder attribute

Translations: French

For years designers have overlaid labels onto input fields in order to save screen real-estate. As front-end developers we implement this using absolute positioning and event handlers to move the label offscreen once the user has focused into the field. User focuses; label disappears.

The placeholder attribute was introduced in HTML5 and has since been misused in order to replicate the functionality described above. Let me set this out very clearly before we move on, the placeholder attribute IS NOT a replacement for a label.

The placeholder doesn’t disappear when it gains focus

Current versions of popular browsers, Chrome 28, Firefox 23 and Safari 6, this is the behaviour. In IE9 & 10 the placeholder disappears on focus.

So, using the placeholder attribute in the prescribed way, as a hint to the value of the field, it displays the following behaviour: user focuses; placeholder remains; user types a character; placeholder disappears.

There has been much debate about how the placeholder should behave.

The HTML5 specification used to be ambiguous in how it should be implemented, hence why browsers had differing behaviour. However, recently the wording “and/or” has been removed:

User agents should present this hint to the user, after having stripped line breaks from it, when the element’s value is the empty string and [used to be and/or] the control is not focused, i.e., by displaying it inside a blank unfocused control and hiding it otherwise.

W3: The placeholder attribute

I think the way the majority of the browsers have implemented is good. For instance, think of the following:

  • an input gains focus on page load
  • you get momentarily distracted after focusing into a field

In both cases, using the correct implementation would mean that the information is effectively lost and could only be readable by removing focus from the field. This would be a particular problem to those with learning or memory difficulties and motor-impairments.

The field looks filled in

I agree that this could be a problem.

As users work through most forms:

1. They see a blank box.
2. They type.
3. The box now looks filled in.

Each time this happens, users learn that

– boxes they need to fill in are blank
– boxes with text in them are already filled in

UX Matters: Don’t Put Hints Inside Text Boxes in Web Forms

This could be addressed in two ways; by changing its colour (see next section) and intelligent copy-writing.

Instead of putting an example of the value that could easily be misinterpreted as a real value:


Consider explicitly showing that it’s an example and use dummy text, such as:


The text is too dark, can we make it lighter?

Nope. But you should probably make sure it’s a different colour to your default input text.

Usually placeholder text is rendered as a light grey colour and it does not provide enough contrast to be readable by all (it does not pass the colour contrast test from WCAG).

You can change its colour using the following code, from CSS Tricks:

::-webkit-input-placeholder {
   color: red;
}

:-moz-placeholder { /* Firefox 18- */
   color: red;  
}

::-moz-placeholder {  /* Firefox 19+ */
   color: red;
   opacity: 1;
}

:-ms-input-placeholder {  
   color: red;  
}

I haven’t come to a conclusion about what colour the placeholder should be, it would depend on your site’s branding but definitely don’t make it any lighter.

Further reading

Add your comment

Your email address will not be published. Required fields are marked *