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

[whatwg] Placeholder option for text input boxes

From: Andy Lyttle <whatwg@phroggy.com>
Date: Tue, 30 Sep 2008 11:46:31 -0700
Message-ID: <FED6356E-CC0A-435A-866F-798189C37FB1@phroggy.com>
On Sep 30, 2008, at 10:54 AM, Tab Atkins Jr. wrote:

> Eh, I'll still complain.  ^_^  While all of your labels *would* be  
> appropriate by themselves, the fact that you have to clarify them  
> means they're not accurate enough for your purposes.

Hey, I never said this was an example of good design - it's just an  
example of using labels for something that shouldn't be rendered as a  
placeholder, while also using placeholders.

> One must also consider the needs of people who are using browsers  
> without the ability to render this placeholder text.  They'll put  
> "long" in hair, "two" in eyes, and "yes" in nose because they can't  
> see the placeholder and are using their keyboard to navigate  
> through your form (and thus won't see the tooltips either).

Hopefully the site will designed well enough that the form is usable  
without the placeholder text or tooltips.  For example, there could  
be instructions outside of the form that explain what is expected,  
with the placeholder serving as a subtle reminder to improve usability.

As for accessibility, the goal is to mark it semantically so user  
agents have the opportunity to render it however is appropriate for  
their users, instead of the current JavaScript hacks that force a  
particular implementation.  Safari is (AFAIK) the only user agent  
that currently implements placeholder; there's no reason to assume  
non-graphical user agents won't implement it in the same timeframe  
that other graphical user agents do.

> Of course, the aesthetics of splitting the description between the  
> <label> and the placeholder text can't always be denied.   
> Semantically, though, you're still using your <label>s as headers  
> in this situation, and then providing the actual labels as  
> placeholder text, and it would *still* be best semantically to  
> either mark it up explicitly as such (move "Hair:"/"Nose:"/etc to a  
> <legend> or <hn> and then <label>ing the fields with "Color:",  
> "Shape", etc) or collapse the hierarchy and combine ( "Hair:"  
> becomes "Hair color:", etc.).

Legend is supposed to label a fieldset, not an individual field.

<fieldset>
     <legend>Facial Features</legend>
     <label for="eyes">Eyes:</label>
     <input name="eyes" id="eyes" placeholder="Color" title="Enter  
the color of your eyes"><br>
     <label for="nose">Nose:</label>
     <input name="nose" id="nose" placeholder="Shape" title="Describe  
the shape of your nose">
</fieldset>
<fieldset>
     <legend>Birth Information</legend>
     <label for="dob">Date of Birth:</label>
     <input name="dob" id="dob" type="date" title="Enter the date you  
were born"><br>
     <label for="birthplace">Place of Birth:</label>
     <input name="birthplace" id="birthplace" placeholder="City,  
State" title="Enter the city and state where you were born">
</fieldset>

> Am I being anal and a little contrived about semantics to support  
> my point?  Of course, but that doesn't make my point invalid.  ^_^   
> After all, what if you wanted hair length as well as color?  You'd  
> be forced to move to one of the two solutions - either promoting  
> "Hair" to a full <legend>/<hn> in the <form> and using "Color:" and  
> "Length" as <label>s or collapsing the label/placeholder dichotomy  
> with "Hair color" and "Hair length" both as <label>s or both as  
> placeholders.

Of course!  If I wanted both hair color and hair length, it would be  
inappropriate to label both of them "Hair", and if I labeled them  
"Hair Color" and "Hair Length", then I wouldn't use "Color" as a  
placeholder (although I might use "Inches").

-- 
Andy Lyttle
whatwg at phroggy.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080930/038bdb61/attachment.htm>
Received on Tuesday, 30 September 2008 11:46:31 UTC

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