55 Minutes

Welcome to the 55 Minutes blog.
55 Minutes is a web development consultancy in San Francisco building apps for design-led businesses and startups. On this blog we discuss the technology tools of our trade: Ruby on Rails, Django, Sass, OS X, and more.

Safari 5.1 and the HTML5 Placeholder Attribute

In a recent release of Safari, Apple elected to deviate from the letter of the HTML5 specification in their implementation of the form input placeholder attribute. With this one change, form entry in Safari is now a much better user experience than either Firefox or Chrome.

According to the HTML5 specification,

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

And up until one of the more recent releases of Safari (5.1.1 at the time of my noticing), all the three major non-IE browsers (Safari, Chrome and Firefox) did exactly that. Once the field gains focus, the placeholder text disappears.

However, a lot of people seemed to have independently arrived at the conclusion that this is not the most user-friendly behavior. It’s much more helpful for the placeholder text to remain visible until the user begins typing, rather than only until the field gains focus; in the time between focusing on a field and beginning to type, it’s easy to forget what’s supposed to go there. This is especially true of forms where the placeholder text is the only indicator of what the field should contain.

So for a while, various sites across the web have implemented this behavior in JavaScript instead, the Twitter and Tumblr login pages not least among them. Now, I’d done the same for a few of our web projects as well, and while the code is relatively straightforward, the timing of hiding the placeholder text can be a bit delicate on page load if the user has form autocomplete enabled and the browser autofills the fields.

Twitter login form
Twitter login form
Tumblr login form
Tumblr login form

Simply put, getting the user experience tuned for maximum usefulness and minimal intrusiveness is not trivial. While both Twitter and Tumblr do a good job with their JS placeholder implementations, other sites get it entirely wrong: the popup Virgin America elevate sign-in form, for instance, puts the “help” text directly in the field as its value, and makes you highlight and remove it yourself. They don’t even do you the courtesy of automatically highlighting the text on field focus so that at least the text disappears when you start typing. It’s a frustrating experience all around.

Update Apr 11, 2012: After this article was posted, Virgin America made some changes to improve the experience of their login form: clicking in the “Email or Elevate #” field automatically highlights the text so that it gets deleted when the user starts typing. However, the password field doesn't behave in the same way. I'm not sure why they didn't make the fields' placeholder text behave consistently, but to their credit, this new behavior is a vast improvement to the old.

Virgin America login form
Virgin America login form

I noticed the other day, however, that the latest version of Safari (5.1.1, possibly earlier) has altered its default behavior so that the placeholder text remains visible until the user begins typing. iOS has been doing this natively for a while, and it’s nice to see that the exact behavior I want is available out of the box. I’ll soon be altering my JS widget to take advantage of the native behavior where it’s available.

To see this behavior in action, load this page in the latest versions of Firefox, Chrome and Safari (8.0.1, 15.0.874.121 and 5.1.2 respectively, at the time of this writing) and try to type in both the text input and textarea below. Only Safari keeps the placeholder text visible until the user begins typing.

comments powered by Disqus