[whatwg] Placeholder option for text input boxes
Tab Atkins Jr.
jackalmage at gmail.com
Tue Sep 30 10:04:21 PDT 2008
On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle <whatwg at phroggy.com> wrote:
> On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote:
>> If and until user enters text, the "alternate" text is displayed.
>> The confusing part is that successfully rendered inputs would be
>> rendered and still use the alt.
>> The good part is that it would be (or should be) accessible for screen
> But alt here as you're describing it doesn't mean the same thing as alt
> anywhere else. On an image, alt text says "this means the same thing as
> what's supposed to be displayed." A placeholder does NOT mean the same
> thing as whatever the user is going to enter.
> On the bright side, doing what you suggest shouldn't break anything because
> I'm sure nobody's using it. However, I don't think that just because we
> have an existing property defined that's used on other tags with a different
> meaning, we should reuse that property for this meaning instead of defining
> a new property.
Agreed. Using @alt is a semantic hack.
For the benefit of myself and others, I'm going to summarize the four
Pro: Already implemented in one major browser. Is opt-in, so doesn't
interfere with existing content at all. Degrades acceptably.
Con: Duplicates semantics already present in <label>, @alt, and @title to
some extent. Is essentially a presentational attribute. Not (currently)
accessible. Won't be widely usable until all browsers support it (ie,
degrades silently rather than usefully).
Pro: Presumably accessible to people with screen readers. Probably not
currently in use at all, so new function won't disrupt existing content.
Con: Semantic hack - it's not "alternative content", it's *normal*
content, just used to introduce the element. May collide with future uses
of @alt if a UI allows form elements to not be displayed (however, no idea
how/why this would work)
Pro: Reasonably semantic. Relatively similar in current usage. Degrades
Con: Good reasons to allow both placeholder text *and* tooltips. Can
break existing content that either expects @title info in a tooltip, or that
has @title that is too long to be placed easily in the <input>. Not
4) <label> (moving label textual content into <input> as placeholder text;
present the desired appearance while keeping the DOM stable)
Pro: Most semantic. Can be pushed site-wide without having to change page
code. Can't break existing content, because it is opt-in (unless this gets
put into browser default stylesheets). Accessible (if using CSS solution;
probably not accessible if DOM mutation is employed). Degrades well (just
stays an ordinary visible label if browser doesn't support the rule).
Con: Most complex solution for implementors. Need to push proposal
through CSS WG, which can be slower than WHATWG.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg