Changes to the HTML5 Placeholder Behaviour

Whilst working on my latest project at Strawberry I got assigned a to-do for a fix. The fix was relating to a placeholder on an input element in Chrome (Mac stable version) that when a text box was given focus, the placeholder text inside it was not disappearing until the user typed (which I will refer to as behaviour 1).

For anyone who hasn’t implemented HTML5 placeholder attributes, the default behaviour in most browsers (which I will refer to as behaviour 2) is that once the input element is focused the placeholder text is hidden allowing the user to type and reappears if the element loses focus (as long as the user hasn’t inputted anything).

Turns out this was not a bug in my coding, but something that Google has either implemented into their browser or something that has somehow crept through as a bug in Canary, Chromium, Dev and Beta builds of Chrome and made it to the stable version, which I fail to believe.

At the time of being assigned this to-do, the behaviour of Chrome on Windows was still handling placeholder as behaviour 2, but from 10th of February, an update to the windows stable build changed this. After dropping this Tweet earlier on, I created a bit of a stir in the office…

The initial feedback I received on Twitter edged towards behaviour 2 that leaving the placeholder text in place on focus would confuse the user. Here is some of the feedback I received on Twitter:

It set me off on a search to find an answer. The first thing I did was open up all the browsers installed on my system and what I found is that at present, most of the browsers still have behaviour 2 implemented with the exception of Safari (Mac only) that has taken the same approach as Chrome, and has surprisingly done so since the release of version 5.1 (currently on 5.1.2). Another thing that I hadn’t noticed is that Safari on iOS devices has been rocking behaviour 1 for some time now.

According to the HTML5 spec, The way Chrome and Safari handle placeholders appear to be incorrect, because it states…

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/or the control is not focused (e.g. by displaying it inside a blank unfocused control and hiding it otherwise).

What intrigues me the most is why Google and Apple have decided to take this route and ignore the spec. I presume they have taken some time to do some real user testing and have reason’s for this change, but unfortunately I am failing to find any documentation showing this. I have checked the Chrome release log and nothing is mentioned about any change to placeholder behaviour and it’s the same with Safari.

I have seen examples on certain sites (Twitter signup form and Facebook’s main search bar for example) where the placeholder text is made lighter on focus giving the user some interaction instead of it doing nothing and this works quite well. What’s bizarre about the Twitter signup form though is that it uses spans instead of the official placeholder attribute, which I am guessing is something used more so for the older browsers that don’t support placeholders.

Although I don’t think there will ever be a perfect right or wrong with regards to this, my personal opinion is that leaving the text there on focus isn’t entirely bad especially if the more mainstream browsers are starting to implement it this way, but I would like to know why they are. I would also say that we definitely shouldn’t be replacing form labels with just placeholders because the spec states this is wrong. We should be using them both alongside each other to make the users experience as easy as possible when it comes to filling out the form.

by