Zach’s ugly mug (his face) Zach Leatherman

Placeholder Title for Article about HTML5 Placeholders

February 05, 2012

When I’m not out fighting crime, I spend my days developing reusable components for the web. One of those reusable components I wrote was an implementation of a placeholder plugin. For the sake of privacy, all component names have been anonymized so I’ll refer to this home-grown implementation as The Mankini (if for no other reason than to drive some swimwear shopping traffic to my blog).

The Mankini’s development predated the HTML5 specification but the end result was functionally similar. The difference being that in addition to operating on text inputs and textareas, it also worked with LF/CR and selects (injects an option with an empty value). The HTML5 specification requires that LF/CR be stripped from the placeholder value.

One of the most important design considerations our interaction design team specified for The Mankini was that it was not to be used as a replacement for a form label. It was a complement to the form label and nothing more. The HTML5 specification came to the same conclusion: “The placeholder attribute should not be used as an alternative to a label.” The reasoning is obvious: if the form field has a non-empty value, you need to be able to easily identify the value’s semantic meaning.

Instead of putting the label text into the placeholder, use the placeholder to supplement the labels with an example e-mail and URL to provide more of a hint to the user for proper formatting. This example isn’t a huge usability issue since the three fields’ values would be easily identifiable, but it’s important to keep in mind.

Placeholder Testing

I decided to run a few compatibility tests on the placeholder attribute to see where I could reuse the HTML5 placeholder inside of The Mankini (the test results are also available on GitHub). This yielded a few interesting things about some consistent and inconsistent cross-browser incompatibilities with the specification that I thought were worth sharing.

  1. The HTML5 spec states that the placeholder should be visible when “element’s value is the empty string and/or the control is not focused.” The and/or presents the implementor with a decision. Do they keep the placeholder text visible when the field is focused but the value is still empty? Or do I remove the placeholder when focusing into an empty field?

    My personal preference is that the text remains until the user starts to type. Safari 5.1, iOS 5, and Chrome 17%2B were the only browser implementations to agree with this as of time of writing.

  2. The HTML5 spec has suggested (not required) that placeholders only apply to <input type="text, search, password, tel, url, email, number"> and <textarea>. For some input types such as hidden, radio, or checkbox this limitation makes sense, the placeholder would add nothing to these elements. But for others like datetime, date, month, week, time, datetime-local, color, or file the argument can be made that it would be useful.

  3. There is an open WebKit issue to add placeholder support to contenteditable. Hopefully the specification gets modified and this gets added, as it would have been useful for my BigText Demo Wizard which manually implemented that same feature.

  4. <input type="number"> support is broken in Safari and it’s already been reported and fixed. “The future is here, just not evenly distributed.”

As a side note, it should be said that both Opera and iOS both have comprehensively badass support of the new HTML5 form element types.

Overlooked Polyfill Considerations

  • For those browsers that did implement the placeholder, it was well supported in password fields, showing as plaintext and then converting to masked input when the user started to enter data. This was a nice surprise, but polyfilling that behavior in old Internet Explorers will require additional lifting since dynamically changing the type attribute is not permitted.

  • Placeholder text should not be included with form submit.

  • Placeholder text should reinitialize on form reset (note: there is no delegate event for reset in jQuery)

  • Performance. Is the component required to iterate over all elements and add a class to initialize each one individually? For best performance, use CSS attribute selectors (input[type="text"][placeholder]) for the default style and iterate only to remove the light gray color on form elements with non-empty values. This only requires a className modification for a much smaller set of elements, only the ones with non-empty values. Remember that the browsers we polyfill are often the slowest.

    Does the component modify the className property on focus and blur? I found this to be a huge performance issue for the Mankini in IE7 and IE8 on pages with large DOM trees and was a lot faster if the Mankini only modified one element’s style (think jQuery’s $(this).css('color', '#000')).

  • Clear the values on page unload. After page refresh, some browsers will attempt to save unsubmitted form values and re-enter the values when the page reloads (added after reviewing Mathias Bynen’s jQuery-placeholder).

Bathwater, No Babies

HTML5 Please recommends that we use the new and shiny responsibly and gives the go-ahead to use the placeholder polyfill on our pages. I humbly disagree. This seems to be the same trap we fell into for rounded corners and box shadows. We put extra effort into trying to get our sites to render and behave identically cross-browser, when we should have just let them render in old browsers without rounded corners or box-shadows at all. To test whether or not a polyfill is necessary, I created a super complex decision workflow called The Polyfill Test. It consists of 2 steps:

  1. Look at your own browser statistics. If the feature is at >50%, continue to Step 2.
  2. Determine if the user will be able to complete their task without the feature. If the task is still completable without significant impairment, the polyfill isn’t necessary.

Globally, placeholder support is sitting at 60% and growing. This particular feature has passed the tipping point. If your audience isn’t a representative sample of the global web browser statistics (big enterprise intranets with 97% Internet Explorer), your mileage may vary.

If you’re already using validation on the form fields (client and/or server side) and you’re correctly using the placeholder to supplement (not replace) the field labels, I would argue that the polyfill isn’t needed. It’s an implementation nice-to-have, not a requirement.

Update: Added note about Chrome 17+ support for placeholder text remaining on focus per Mathias’ feedback below.

< Newer
Let&#8217;s get parseIntimate.
Older >
Deferreds and a Better Geolocation API

Zach Leatherman IndieWeb Avatar for a builder for the web and the creator/maintainer of IndieWeb Avatar for https://www.11ty.devEleventy (11ty), an award-winning open source site generator. At one point he became entirely too fixated on web fonts. He has given 81 talks in nine different countries at events like Beyond Tellerrand, Smashing Conference, Jamstack Conf, CSSConf, and The White House. Formerly part of CloudCannon, Netlify, Filament Group, NEJS CONF, and NebraskaJS. Learn more about Zach »

1 Repost

IndieWeb Avatar for
  1. marcusklaas Disqus

    06 Feb 2012
    Although I was originally looking for a yellow men's bathing suit, I still enjoyed this article. I agree especially with your view on polyfills.
  2. Mathias Bynens Disqus

    06 Feb 2012
    My personal preference is that the text remains until the user starts to type. Safari 5.1 and iOS 5 were the only browser implementations to agree with this as of time of writing.FWIW, Chrome 18 Canary does this too. I’m not sure when exactly this landed though; it may have already worked like this in Chrome 17 as well.
  3. Mathias Bynens Disqus

    06 Feb 2012
    polyfilling that behavior in old Internet Explorers will require additional lifting since dynamically changing the type attribute is not permitted.Old Firefox (3.6 and older IIRC) have the same problem.
  4. Zach Leatherman Disqus

    06 Feb 2012
    marcusklass: Disappointment tempered!Per usual, you're right Mathias. The remove-on-value feature is implemented in Chrome 17-beta.
  5. KMB Disqus

    24 Feb 2012
    In my experience it's very confusing to have the placeholder text visible after the input has focus. Not so experienced users will try to delete the text first before typing or even try to select it all with the mouse/keyboard (mostly mouse) in order to "overwrite" it. Therefore I'm in the "focus and it's gone"-department.It can be argued, that the placeholder has already been read and understood by the user once he/she focus on the input-field and further presence of it leads only to confusion instead of support.This might be a trap for auto-focusing those fields.
  6. Paul Irish Disqus

    06 Mar 2012
    Zach, you should file a ticket on the h5please repo about recommending polyfill for placeholder. I think it's a great discussion to have.IMO, if you want the behavior of a placeholder that acts as a label.. you'll need a polyfill. Also a placeholder for telephone number like xxx-xxx-xxxx is probably useful, else you'll screw up the expected formatting. So yeah I think you most of the times need a polyfill for something as meaning-giving as placeholder.
  7. Dirk Ginader Disqus

    14 Mar 2012
    I'd like to add one more item to your excellent list of Overlooked Polyfill Considerations:--> Screenreader accessibility of the placeholder text.The way that most Polyfill implementations work is to have form elements that get filled with the placeholder text and emptied again on focus. This way the Placeholder text is never exposed to Screenreaders though (as the text is already gone when the field is read).To work around that issue my Placeholder Polyfill writes the placeholder text into a separate part of the label and positions this over the form fields. By doing this Screenreader users now have a chance of reading the Placeholder text as well. What do you think?
  8. Zach Leatherman Disqus

    14 Mar 2012
    @Paul: I'm not convinced that there are cases in which you'd want the placeholder to act as a label? It's the same argument that's been made for placing mobile form field labels above the fields: the users want to be able to see the label once they've focused into the field (even if that field already has a value). I would also say that formatting is better solved by input masks and client side validation. But we can continue that discussion on the ticket: Is the accessibility behavior improved with the remove-on-typing behavior? Of course, my current position is that I probably won't use a polyfill in new projects moving forward unless there is an overwhelming IE audience.
  9. Dirk Ginader Disqus

    14 Mar 2012
    @Zack: technically the accessibility of the fake placeholder is better as the content will be exposed to but on the other side it's a very unexpected behavior to:- enter a field- reading the prefilled value of the field- probably trying to clear the fields value- having the text suddenly disappear without knowing whyWith the native Placeholder this is not an issue. With the polyfilled version it is.
  10. JMH Disqus

    30 Jan 2015
    I agree that it is best to have the placeholder disappear as soon as the field is focused. Otherwise, my natural reaction is to first select/delete it. My solution to this was to add focus and blur functions to replace the 'placeholder' with nothing, then restore it. Only downside is that you have to keep track of or otherwise know the placeholder text string so you can restore it.
Shamelessly plug your related post

These are webmentions via the IndieWeb and

Sharing on social media?

This is what will show up when you share this post on Social Media:

How did you do this? I automated my Open Graph images. (Peer behind the curtain at the test page)