Re: Placeholder Text for Text Boxes

A good idea.

An alternative option would be to introduce a new element, e.g. <hint
for="id-of-control">Hint text here</hint>.

Similar pros and cons with the additional notes (perhaps?) that:
- Con: some browsers have implemented @hint, none having implemented <hint>
- Pro: browsers that have not implemented <hint> will render its
contents (this would be my preference for backwards compatibility)
- Pro: association with form element could be achieved by nesting
<hint> within an associated <label> element: e.g. <label
for="some-id">Label: <hint>(hint here)</hint></label>
- Pro: potential to use richer markup (e.g. links, <kbd>, <em>, etc.).

n.b. <hint> exists in XForms:
http://www.w3.org/TR/xforms/slice8.html#ui-commonelems-hint

Do we have a wiki page where I can add all this?

cheers
Ben


On 8/21/07, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
>
> Hi,
>    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
> misused.)
>
> 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
> solutions:
> (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
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/000824.html
>
> Input field's hint value
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-February/009531.html
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-February/009558.html
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-February/009548.html
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-February/009558.html
>
>
> 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
> adopted.)
>
> * 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
>    implemented.
>
> - 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
> http://lachy.id.au/
>
>

Received on Tuesday, 21 August 2007 14:34:11 UTC