- From: Ben Boyle <benjamins.boyle@gmail.com>
- Date: Wed, 22 Aug 2007 00:33:59 +1000
- To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
- Cc: public-html <public-html@w3.org>
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