At the beginning of July 2012 I wrote an article about a custom [placeholder]
solution we integrated at XING. The idea was to have placeholders that should still be visible when focused (see “placeholder – Custom solution vs. native HTML5 feature”).
As mentioned in that article, Chrome at one point natively handled what we implemented in a heavily jQuery based way. Having that said, it means they went against the specification, which may seem weird, but no one ever said that a specification is set in stone. (I’ll refer to that again later.)
Other browsers handle this the same way in their newer versions (Safari, Firefox) with the placeholder presented to the user while the input is focused. Both solutions have their advantages and disadvantages, and I’m happy with both of them.
Keeping the placeholder visible on focus… wait a sec. Wasn’t that what we developed already? The outcome of this was that we threw all the custom handling out of the code and used the plain and simple [placeholder]
attribute. As well as a label informing us about what should be entered, we can also display an example to the user. By moving on in their release cycles, the browsers supported ways of changing the placeholder style.
/* * Safari has kept the placeholder visible and the input focused since version 6 * and since version 17 in Chrome (guessing from the WebKit version 535.11 * in which this change was introduced) */ /* Safari 5+ (3.1+ lacking) / Safari iOS 3.2+ / Chrome 4+ */ ::-webkit-input-placeholder { color: #a9a9a9; } :focus::-webkit-input-placeholder { opacity: 0.8; } /* IE 10 */ :-ms-input-placeholder { color: #a9a9a9; opacity: 0.8; } /* commented out because IE10 hides the placeholder when focused :focus:-ms-input-placeholder { color: #a9a9a9; opacity: 0.5; } */ /* Firefox 19+ (Gecko 19+) */ ::-moz-placeholder { color: #a9a9a9; opacity: 0.8; } :focus::-moz-placeholder { opacity: 0.7; } /* * Firefox has kept the placeholder visible and the input focused since version 15 * * http://www.mozilla.org/en-US/firefox/15.0/releasenotes/buglist.html * https://bugzilla.mozilla.org/show_bug.cgi?id=673873 */ /* Firefox 4 - 18 (Gecko 2 - 18) */ input:-moz-placeholder, :-moz-placeholder { color: #a9a9a9; opacity: 0.8; } input:focus:-moz-placeholder, :focus:-moz-placeholder { color: #a9a9a9; opacity: 0.5; } |
And of course the markup is markup we love. :)
<input type="text" name="foo" placeholder="bar" size="10"> <br> <textarea name="foo_text" placeholder="bar text" cols="10" rows="4"></textarea> |
This is just an example (the styles shown above are not applied):
As time goes by even a specification changes. The current HTML5.1 nightly specification (Editor’s Draft 15 April 2013) states:
User agents should present this hint to the user [...] when the element’s value is the empty string or the control is not focused (or both) [...].
(so they also kind of adopted as well in a way because it’s not explicitly forbidden to show the placeholder if the input is empty and focused)
We decided to only write a fallback for Internet Explorer 8 and 9. Both of them are still used widely. We’re checking IEs whether the placeholder attribute is supported or not.
// we already excluded IE lower than or equal 7 at this point if (!("placeholder" in document.createElement("input"))) { // handle fallback case // which is summarized by an element behind the input. the tricky // part about this is that an input with a transparent // background and an element with text behind can cause a // well I would say "event trap" // a good explanation can be found here: // http://blog.rednael.com/CommentView,guid,518600bc-c062-4657-bd25-5aae64d32c1d.aspx } |
Text areas are only partially supported in Opera 11.0 – 11.5 and Safari 3.1 – 4.0, but this is acceptable. (People, update your browsers!) Fun fact: iOS Safari has full support starting in version 3.2. ;-)
Conclusion
Browsers and specifications evolve and so does XING. While browser vendors started to implement the placeholder, we chose another way by introducing a custom user experience. Some of the browser vendors decided this is the direction to go, so the only thing that needs to be done is to reduce the markup and set up the JavaScript logic for IE only. Besides saving bytes (when downloading), this also saves a lot of event listeners and DOM accesses while the page is running and the user wants to interact.
Custom solutions are never easy to build so we should always think about whether it is worth it from more than one perspective.
- List of references
- http://devblog.xing.com/frontend/placeholder-custom-solution-vs-native-html5-feature/
- http://stugreenham.com/articles/changes-to-the-html5-placeholder-behaviour/
- http://www.mozilla.org/en-US/firefox/15.0/releasenotes/buglist.html
- https://bugzilla.mozilla.org/show_bug.cgi?id=673873
- http://www.w3.org/html/wg/drafts/html/master/forms.html#the-placeholder-attribute
- http://caniuse.com/#search=placeholder