W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2013

Re: [whatwg] Hide placeholder on input controls on focus

From: Kit Grose <kit@iqmultimedia.com.au>
Date: Wed, 20 Mar 2013 01:20:58 +0000
To: Tim Streater <tim@clothears.org.uk>
Message-ID: <7A8C8ADF-5C3D-4C84-88EF-51EEB36EDD84@iqmultimedia.com.au>
Cc: "<whatwg@lists.whatwg.org>" <whatwg@lists.whatwg.org>, Markus Ernst <derernst@gmx.ch>, Glenn Maynard <glenn@zewt.org>, Boris Zbarsky <bzbarsky@mit.edu>
On 20/03/2013, at 1:42 AM, Tim Streater wrote:

> On 18 Mar 2013 at 23:44, Glenn Maynard <glenn@zewt.org> wrote: 
> 
>> On Mon, Mar 18, 2013 at 12:51 PM, Markus Ernst <derernst@gmx.ch> wrote:
>> 
>>> A reason for the behaviour of Firefox and Chrome may be that some user may
>>> not have read the placeholder text before focusing the control. Anyway, if
>>> this behavior lets some users think they can't even fill in the form, there
>>> must be something wrong about it.
> 
>> I've seen browsers (or maybe pages emulating placeholder in script) that
>> hide the placeholder text while the input field is focused.  When the
>> placeholders are labels for the inputs, it's incredibly annoying to have to
>> focus something else in order to see the placeholder text.  If placeholders
>> are meant to be useful and not just eyecandy, they need to remain visible
>> until the user enters something.
> 
> But that's not what users do. You read the placeholder text, which may may hint at what is expected there, and the field should have a separate label. Then you focus there, and the placeholder text should vanish. Why? because I've lost count of the number of users I see trying to select the placeholder text so they can delete it, and then start typing.

I believe this issue—in the limited situations it presents itself—is more a factor of the treatment of the placeholder itself than the existence of a placeholder.

One of the key benefits of the HTML5 placeholder attribute is the standardisation of its presentation and behaviour, so it can eventually become more predictable to users. Right now, Safari uses an input with a placeholder string for its URL bar ("Search Google or enter an address"), Chrome uses one in its settings interface ("Search settings"), Firefox uses one for its awesomebar ("Go to a Web Site") and for its search field ("Google"). Opera uses one for its search field too ("Search with Google"). Internet Explorer seems to be the only browser left that _doesn't_ do this (although it used to in IE8, when its search field said, e.g. "Live Search").

Facebook uses a placeholder for pretty much every form they have (including their search form and wall submission form). Wikipedia uses it for its search form too.

In almost every case the placeholder remains visible until the user has begun typing, as I strongly believe it ought to be remain in the specification, since it provides the contextual hint for as long as possible.

That it has historically been implemented in a way that implies selectable content is, I believe, chiefly due to the lack of support for a "right" way to do this (which has led many developers to implement the placeholder text simply by setting the field's value to the placeholder text as the simplest implementation).


Kit Grose
User Experience + Tech Director,
iQmultimedia
Received on Wednesday, 20 March 2013 01:22:25 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 20 March 2013 01:22:26 GMT