[whatwg] Placeholder option for text input boxes

[Tab Atkins Jr.]

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
>> readers.
>>
>
> 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
current proposals.

1) @placeholder
  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).

2) @alt
  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)

3) @title
  Pro: Reasonably semantic.  Relatively similar in current usage.  Degrades
acceptably.
  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
accessible.

4) <label> (moving label textual content into <input> as placeholder text;
currently with Javascript to mutate the DOM, in the future with CSS to
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.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080930/0da19983/attachment-0001.htm>