[whatwg] Placeholder option for text input boxes
Tab Atkins Jr.
jackalmage at gmail.com
Tue Sep 30 12:06:12 PDT 2008
On Tue, Sep 30, 2008 at 1:46 PM, Andy Lyttle <whatwg at phroggy.com> wrote:
> On Sep 30, 2008, at 10:54 AM, Tab Atkins Jr. wrote:
> 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.
> <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">
> <legend>Birth Information</legend>
> <label for="dob">Date of Birth:</label>
> <input name="dob" id="dob" type="date" title="Enter the date you were
> <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">
Is this (the splitting of necessary descriptive information between label
and placeholder text) sufficiently widespread enough to justify designing
toward it? In every use of placeholder text *I've* seen in the wild, it was
*only* used as a label *replacement*, not an augment. Frex, a forum I
frequent has username and password fields shoved away very compactly into an
infobar at the top of the screen, and uses placeholder text to indicate what
they are for. You've provided cases where it *could* be useful, but in each
of these it would be just as useful to the user to have that information in
the label itself. It's really just the designer's aesthetic concerns that
dictate it must be separated. Obviously this entire discussion is about
mere aesthetics ultimately, but if a qualitatively better answer will solve
90% of use cases with greater ease, accessibility, and less coding, we
should probably go with it. I'm arguing that a CSS-based packing of the
<label> text into the input is just such an answer.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg