Cross-Browser HTML5 Placeholder Text

Posted by on Mar 29, 2011 in Blog | 16 comments

One of the nice enhancement in HTML5 web form is being able to add placeholder text to input fields. Placeholder attribute allows you to display text in a form input when it is empty and when it is not focused (it clears the field on focus). This is a nifty feature, but it is not [...]

View full post on Web Designer Wall – Design Trends and Tutorials

Incoming search terms:


  1. That’s all very well, but why not just use the jQuery code and not bother with the HTML5? This would mean you don’t have to add modernizr to your page load.

  2. The JS could be better. In general, avoid to select twice the same DOM elements. Store stuff in variables if nesseserly. And you should use ‘===’ instead of ‘==’ and i wonder why you need a second .blur() after the .blur()…

  3. Thanks for the helpfull article.
    I believe it’s quite common to remove the ‘Chrome’ borders of input boxes with outline:none (on the :focus) state. What’s the difference between this method and input[type="search"]::-webkit-search-decoration?

  4. what about password input?

  5. I fail to see how this is better than value.

  6. I agree with Doug Neiner here, I think label is still required in web form. Label and placeholder serve two different purposes. Placeholder is not equal to label.

    The entire point of my demo is just to show placeholder (not web standard form). Hence I didn’t even put a submit button in the form.

  7. You might be interested in “Formalize CSS”

    It also removes the placeholder text, if you submit the formular, so there is no wrong data submitted.

  8. Jonathan, but they serve completely different needs. Even though the HTML5 spec isn’t finalized, the goal of a placeholder is quite different than a label. A label also provides screen-readers with essential information about the field. I am not sure how they do with placeholders. Even though web standards have been widely adopted, mis-using an attribute or element is just as bad as it ever was.

  9. Well Jonathan, I think that’s different with every person.
    Personally I really really hate it when my label is gone on focus. Because I tab all my forms, I don’t see what type of input is needed in the next inputfield.
    So I have to make 2 extra tabs, to see what inputfield I have when there is no seperate label.
    But hey, that’s me of course

  10. I think it’s fine to use placeholders as a replacement of labels, it’s cleaner and more condensed. It’s not apart of yesterdays semantic web, but i think tomorrow it should be.

  11. That’s a debate I’ve had with a few people, too many treat it like a label where as a placeholder should simply show the format of an input and not be it’s label.

  12. Though my comment here doesn’t change the *technical* aspect of the post (providing a fallback for placeholder), I think there is a large problem with the use case of the placeholder.

    There is a difference between the HTML5 placeholder, and what I call an in-field label (What you are actually showing in this post). The placeholder is supposed to show *how* the user should input data. An in-field label serves the same purpose as a real label, only it appears in (or over) the field.

    Here are some examples of the difference:

    Label: Email

    Label: Phone number
    Placeholder: 413-123-4567

    Just because the HTML5 placeholder looks like in-field labels we see around, it doesn’t serve the same purpose. If you plan to use the placeholder attribute, you should probably also provide a label.

  13. This is a useful resource for seeing what attributes are supported by the modern browsers when styling the placeholder.

    It’s not possible to style the placeholder at all in IE9, Opera 10 (and below) or Firefox 3.6, and the rest also have mixed support.

  14. I read your post Dave, but I think it’s fine to use it. Only thing I could think of is if you don’t have a seperate label, an older browser, and no Javascript enabled. You don’t see any hints about the field. But hey, who doesn’t have Javascript these days.
    But I think it’s just great to use this new feature.

  15. That’s a great feature. Last week I made something like that, but than for Mootools cause I like it better:

    But it’s a powerfull css feature

  16. I posted something similar a while ago on my own blog

    There were concerns raised in the comments about the accessibility of injecting text into the val attribute, personally I think used sensibly and as long as the text is injected with JavaScript then it should be fine, maybe some readers here have a different view?