W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] Placeholder option for text input boxes

From: Andy Lyttle <whatwg@phroggy.com>
Date: Sat, 4 Oct 2008 17:41:17 -0700
Message-ID: <12D8CE8D-3528-4806-B8B5-4DED6C6826C7@phroggy.com>
On Oct 4, 2008, at 3:38 PM, timeless wrote:

> On 10/3/08, Adrian Sutton <adrian.sutton at ephox.com> wrote:
>>  Placeholder ... aids usability
>
> having recently fought with some javascript which tried to enhance my
> ability to enter text ('crash' in a keyword chooser using nokia's
> webkit based browser on my phone), I'd like to remind people that
> someone's "usability" aid is someone else's nightmare. the problem
> there didn't need solving as the browsers we have either support
> remembering text-input or have keyboard support or are so slow that
> the chooser hangs them....
>
> i use quite a few browsers where javascript is disabled and in many of
> them, clearing a text field is extremely painful (especially the phone
> cases).

The existence of a "placeholder" attribute in HTML should discourage  
web developers from using crazy Javascript hacks that don't work  
correctly on a cell phone.  In particular, it means NOT "faking it"  
by setting the value of the field to an obnoxious string that doesn't  
get cleared.  Browser developers such as Nokia can display  
placeholder text in whatever way makes the most sense on their  
platform, without using JavaScript at all.

Most mobile browsers I've used switch to a text input dialog as soon  
as the control is focussed.  I would display the placeholder on the  
web page the same way any other browser would, but not display it on  
the text input dialog.  Someone else might choose to go ahead and  
display it on the text input dialog as well (above the input field),  
with the placeholder text not disappearing while text is being entered.

> my devices aren't powerful enough to support true accessibility
> features, but in some ways they want them- especially to turn off all
> of these glitzy web "features" which significantly impede my ability
> to get work done.
>
> sometimes enabling a designer to do something is the wrong decision.
> google and skype both can convert all numbers they see into very
> annoying and generally incorrect tel: links. skype's toolbar can
> thankfully be disabled, however the gmail mobile one can't be, which
> means I'm stuck with unusable (and unreadable) content.

Enabling a designer to use placeholders is a moot point; they're  
already doing it, in a non-standard buggy way that breaks on your  
phone.  We want to give them semantic markup that will behave the way  
they want in their browser, while still being perfectly usable on  
your phone so they can quit using annoying hacks.  Placeholder  
shouldn't be "glitzy" and absolutely should never impede your ability  
to get work done; if it does, somebody screwed up their implementation.

> placeholders are interesting, but will the resources required to
> support them be better than telling designers just to make their
> label's clearer?

I don't expect the required resources to be significant, but I'm not  
a browser developer...

> for my devices, I'm going to need a way to disable them and something
> tells me that even if  we were to standardize on a way to present
> placeholders, I'll still be unable to suppress many implemented in
> javascript/css.

This is true.  Adding placeholder to HTML doesn't mean web developers  
will immediately drop their JS/CSS hacks, because existing browsers  
don't support placeholder.  But over time, as everybody upgrades  
their browsers and developers stop caring about the people still  
using older browsers, the problem should slowly fade away.

> - this complaint was composed using an n800 because symbian brutally
> killed my gmail client and the web browser.

My N75 won't load more than a few pages before the browser stops  
working entirely and I have to reboot the phone.  Sucktacular.

-- 
Andy Lyttle
whatwg at phroggy.com
Received on Saturday, 4 October 2008 17:41:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC