<div dir="ltr">On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle <span dir="ltr"><<a href="mailto:whatwg@phroggy.com">whatwg@phroggy.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If and until user enters text, the "alternate" text is displayed.<br>
<br>
The confusing part is that successfully rendered inputs would be<br>
rendered and still use the alt.<br>
<br>
The good part is that it would be (or should be) accessible for screen readers.<br>
</blockquote>
<br></div>
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.<br>

<br>
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.<font color="#888888"></font></blockquote>
<div><br>Agreed.  Using @alt is a semantic hack. <br></div></div><br>For the benefit of myself and others, I'm going to summarize the four current proposals.<br><br>1) @placeholder<br>  Pro: Already implemented in one major browser.  Is opt-in, so doesn't interfere with existing content at all.  Degrades acceptably.<br>
  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).<br>
<br>2) @alt<br>  Pro: Presumably accessible to people with screen readers.  Probably not currently in use at all, so new function won't disrupt existing content.<br>  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)<br>
<br>3) @title<br>  Pro: Reasonably semantic.  Relatively similar in current usage.  Degrades acceptably.<br>  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.<br>
<br>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)<br>
  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).<br>
  Con: Most complex solution for implementors.  Need to push proposal through CSS WG, which can be slower than WHATWG.<br><br>~TJ<br></div>