W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Placeholder Text for Text Boxes

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Tue, 21 Aug 2007 00:47:05 +1000
Message-ID: <46C9A969.2060900@lachy.id.au>
To: public-html <public-html@w3.org>

   Many sites often use various techniques to provide default text in 
text boxes, which is typically removed upon focus using a script.  The 
purpose of this text is to provide a hint to the user about the purpose 
of the field or expected content.

(I'm also using this as an example to demonstrate how various design 
principles are intended to be applied, since there still seems to be a 
lot of confusion about how to apply them and concern about them being 

Use cases and examples
(Design Principle: Pave the Cowpaths):

This is often seen on various sites using values such as "Enter search 
terms", "Search", "Username", and many other similar values.

* http://www.apple.com/
   The search box in the top right corner of the page contains the text
   "Search" as a place holder.

* http://www.unwired.com.au/
   The username and password fields contain the text "Username" and
   "Password" respectfully.

(Note that, as demonstrated here, Pave the Cowpaths is about 
investigating and addressing the existing practices and use cases, not 
necessarily adopting the solutions.)

There are numerous problems that need to be solved with the existing 
(Design Principle: Solve Real Problems).

1. Accessibility issues are caused because the value is typically 
cleared on focus, and so assistive technology would miss out on reading 
the value.

2. The technique doesn't work well with password fields, since the value 
is rendered as asterisks or dots.  The Uniwired example above actually 
positions text box on top of the password field which is then removed 
upon focus to achive the effect.

3. Depending on how well the JavaScript used to implement this, numerous 
accessibility and usability issues can occur.  In extreme cases, some 
scripts will clear the value every time the field is focussed without 
checking the value.  So a value previously entered by the user would be 
cleared. In the Unwired example, the text field containing "Password" is 
not removed upon focus, and so it's not possible for a user without JS 
enabled to enter a password.

Previous discussion of this issue has occurred on the WHATWG list.

Question about "Type here your search word(s)" input box

Input field's hint value

Possible Solutions:

* Adopt the existing JavaScript solutions
(Design Principle: Don't Reinvent the Wheel)
Pro: Already in use
Con: See major problems listed above

(Note that even though Don't Reinvent the Wheel is being applied here, 
the existing solutions do need to be evaluated and not just blindly 

* Re-purpose the title attribute
Pro: Degrades gracefully in existing UAs.  The value is still available 
via a tooltip (or equivalent) in existing browsers.
Con: Will potentially break many existing pages, since it introduces new 
and unexpected behaviour for an existing attribute.

* Introduce a new attribute
Pro: Solves the accessibility problems with the JavaScript solution
Pro: WebKit already implements the placeholder attribute for this purpose
Pro: Very simple for authors to use
Con: Doesn't work in all existing UAs.
Con: Difficult to simulate with JavaScript (see above problems with 
JavaScript techniques)  The value could be repeated in the title 
attribute as a workaround, which would at least make the value available 
to users.

Possible new attribute names:
* hint
* placeholder

The advantage of placeholder is that it's already implemented in any 
browser using WebKit (Safari on Mac, Windows and the iPhone, and many 
new Nokia mobiles).

Design Principles:
- Degrade Gracefully: workarounds are available for existing UAs that
   don't support this.

- Don't reinvent the wheel: The placeholder attribute is already

- Pave the Cowpaths: "Leverage the existing techniques and skill sets
   of authors" - authors know how to add attributes, the existing
   techniques use the value="" attribute.

- Universal Access: the value can be exposed in any way required.
   Screen readers, for example, can read the value and speak it.

- Avoid Needless Complexity: a single new attribute is very simple for
   authors.  The existing implementation demonstrates that it's possible
   to implement.

Lachlan Hunt
Received on Monday, 20 August 2007 14:47:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC