[whatwg] <input placeholder="">

[Ian Hickson]

On Wed, 21 Feb 2007, Wolfram Kriesing wrote:
>
> I was searching, but didnt find a hint-attribute for an input. The
> more often we are using inline editing, the more the need for the
> following is rising, imho:
> 
>   <input type="whatever" hint="Enter your title here" />
> 
> The text "Enter your title here" is shown as the value while no value is 
> given, or when the field is empty, upon focusing the element this string 
> disappears. If no value was entered this text is shown again ... I guess 
> its clear what I think of here, a lot of apps already have that.

On Mon, 21 May 2007, Stijn Peeters wrote:
>
> It is becoming increasingly common to have an input field clear its 
> value when it is first focused. Though in a lot of cases this is 
> actually wrong usage of the value=""  attribute for something which 
> should actually be done with <label> (such as a search box filled with 
> "Enter search query here" that becomes empty when you first click it), 
> it is possible to come up with legitimate use cases; the first thing 
> that comes to mind are input fields with placeholder or default values 
> that may need to be changed. This goes well together with WF2's new 
> abilities for prefilling forms.
> 
> It makes sense to clear these values when the field is focused, as the 
> user will probably want to insert a new value rather than edit the value 
> that is currently in it. Currently this is mostly done through 
> javascript, which is not necessarily a bad thing, but seeing that 
> attributes such as autofocus=""  have also found their way into the 
> spec, I suppose this is also inside the scope of Web Forms 2 or HTML5. 
> As for the attribute name, clearonfocus="" with "clearonfocus" as the 
> only possible value (indicating the input field or textarea should be 
> cleared upon focusing it) would probably be most suitable.

On Mon, 21 May 2007, Anne van Kesteren wrote:
> 
> WebKit implements a placeholder= attribute which seems more suitable for 
> this purpose.

On Mon, 29 Sep 2008, Andy Lyttle wrote:
> 
> There's one particular feature that would be easy to adopt without 
> supporting the rest, and that's the "placeholder" option.  Currently, 
> lots of sites are implementing placeholder text through a combination of 
> creative CSS and JavaScript hacking, but each site has to reinvent the 
> wheel, and very often the wheel gets reinvented badly (examples below).  
> Making it a standard feature of HTML would eliminate the need for all 
> the extra scripting and improve accessibility, and consistent behavior 
> would make a better user experience.
> 
> The desired behavior is for the placeholder text to appear in the field 
> with a gray color when the field is not focused and the value is empty.  
> Of course the meaning of "gray" is up to the browser.  The placeholder 
> option was originally intended for search fields, but it's useful for 
> other input types as well, and Safari already supports it on all text 
> input fields.  The HTML simply looks like:
> 
> <input name="zip" placeholder="Zip Code">
> 
> Here are a bunch of examples of sites that currently use JavaScript and 
> CSS tricks in an attempt to simulate this behavior, to varying degrees 
> of success [...]

On Mon, 29 Sep 2008, Maciej Stachowiak wrote:
> 
> I would love to see the placeholder="" attribute become standard parts 
> of HTML5. We invented these extensions originally for non-Web content, 
> but they seem useful for the Web and of interest to Web content authors.
On Fri, 3 Oct 2008, Tab Atkins Jr. wrote:
> 
> Man, I could *really* see the "hint" function being viable and quite 
> useful.  It offers up a completely new-and-useful semantic, and there's 
> no particular place it should already go.  I'd accept this as a new 
> attribute without reservation if it was renamed @hint, so it's 
> absolutely clear what the semantic for it is.
> 
> We can then delay any questions of generalizing this function with CSS 
> until later, and get this pushed into html5 immediately.
> 
> For now, people wanting to use hint-like appearance for their labels but 
> stay semantic can just use the established javascript hackery.

On Fri, 3 Oct 2008, Andy Lyttle wrote:
> 
> The only reason to use placeholder instead of hint is that Apple already 
> implemented placeholder.  Documentation should explain that placeholder 
> is to be used for hints, not for labels (and people can then ignore the 
> documentation and use it for labels anyway, but at least we tried).

On Sat, 4 Oct 2008, Tab Atkins Jr. wrote:
> 
> Well, we don't really have interop yet, since *only* Webkit implements 
> it currently, and officially only on a single non-standard input type 
> (though it happens to apply to text and similar input types).  If we can 
> shift the name over *now*, before FF implements it fully, it would 
> probably be fine.
> 
> On the other hand, I don't want to be one of those jerks who tries to 
> block a feature solely because they don't like its name.  However, it's 
> a proven fact that most people don't look at documentation *ever*, and 
> so having the name provide a perfectly intuitive hint for what the 
> attribute is supposed to do would probably be best.  At the very least 
> it would set up some cognitive dissonance for people using it as a 
> label, hopefully.

On Sat, 4 Oct 2008, Maciej Stachowiak wrote:
> 
> I think "placeholder" is as good a name as "hint"; it may sound less 
> "semantic" but it's more clear that it would result in a tooltip like 
> "title" would. That being said, it would not be an excessive burden for 
> us to support "hint" as well as "placeholder" for compatibility.

Added, called placeholder="".


On Wed, 21 Feb 2007, Alexey Feldgendler wrote:
>
> From the semantic standpoint, I believe this is what the title attribute 
> expresses.

No, title="" is for a longer hint.


On Tue, 22 May 2007, Charles Iliya Krempeaux wrote:
> 
> It's a Usability issue mixed with a Graphical design / aesthetics 
> issue.,
> 
> You need a label for the field... but don't want to put one beside it. 
> So the label goes inside the field... until you click on it.  (At which 
> point the label disappears.)

This isn't a label replacement really. The only time that I can think of 
where omitting the label might work is for the type=search idea, if we add 
it, since then the shape of the field is self-explanatory. But that would 
be true regardless of placeholder=""'s existence.


On Wed, 23 May 2007, Matthew Paul Thomas wrote:
> 
> I don't understand. What use is a default value if you can't edit it? 
> Why not make the field empty to begin with?

On Fri, 25 May 2007, Matthew Paul Thomas wrote:
> 
> No, we already addressed the label use case. I asked specifically about 
> the default value use case.

I don't know what you are asking for here.


On Mon, 29 Sep 2008, Garrett Smith wrote:
>
> |placeholder| sounds a little like |alt|. Alt is a property and an 
> attribute on INPUT.
> 
> How to specify alternate text: 
> http://www.w3.org/TR/html401/struct/objects.html#adef-alt

On Tue, 30 Sep 2008, Benjamin Hawkes-Lewis wrote:
> 
> How is placeholder content for a form field alternative text?

On Tue, 30 Sep 2008, Jonas Sicking wrote:
> 
> The alt text is for situations where the <input> can not be displayed at 
> all. For example an <input type=image> where the image fails to load or 
> the user has disabled. Or you could imagine in theory if the UA 
> supported turning off form controls entirely.
> 
> The placeholder is content that is displayed along with a rendered form 
> control.
> 
> Thus placeholder is used along with the form control, alt is used 
> instead of it.

On Tue, 30 Sep 2008, 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.

On Tue, 30 Sep 2008, Andy Lyttle wrote:
> 
> 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.

On Tue, 30 Sep 2008, Tab Atkins Jr. wrote:
>
> Agreed.  Using @alt is a semantic hack.

alt="" is about not dispaying images, it has nothing to do with 
placeholder values. I think it would be highly confusing to mix the two 
cases here.


On Tue, 30 Sep 2008, Nils Dagsson Moskopp wrote:
>
> No, I meant to abolish the placeholder attribute alltogether and render 
> the title attribute as greyed-sut inside the search box instead, because
>
>       * semantically, the title attribute conveys the same information.
>
>       * it is already there in many pages.

On Tue, 30 Sep 2008, Andy Lyttle wrote:
> 
> Except that:
>
> 1) the title attribute doesn't behave this way on any other element
>
> 2) there's no reason it shouldn't be possible to have both a placeholder 
> AND a tooltip
>
> 3) anybody who is currently using the title attribute doesn't expect it 
> to be displayed as a placeholder, so we would break things for them 
> (especially if their title string is too long to fit inside a small 
> field)

We can't really change the behavior of title="" now, it'd have all kinds 
of weird unexpected effects on existing pages.


On Tue, 30 Sep 2008, Andy Lyttle wrote:
> 
> As I understand it, it was sort of an accident that Safari supports 
> placeholder on anything other than search fields, but there's no reason 
> it shouldn't apply to all text input fields including textarea.
> 
> I've just filed https://bugs.webkit.org/show_bug.cgi?id=21248

I've made it (in the spec) apply to types text, email, url, and password.


On Wed, 1 Oct 2008, Kristof Zelechovski wrote:
>
> Please demonstrate a *valid* example of a placeholder containing a hint.

Included examples in the spec.


On Wed, 1 Oct 2008, Kristof Zelechovski wrote:
>
> Accessing attributes as properties is discouraged and considered 
> becoming obsolete; it should not be expected to work for new attributes.

As far as HTML5 is concerned, DOM attributes aren't deprecated. I am 
disregarding DOM2's IMHO misguided advice.


On Wed, 1 Oct 2008, Garrett Smith wrote:
> 
> Other INPUT attributes work don't reflect.

I have no idea what this means.


> The way I would imagine |placeholder| would work (and imagining is about 
> all I can do at this point) is that |input.placeholder| would be a DOM 
> property.  It wouldn't necessarily reflect[1] the attribute value; 
> changing input.placeholder would not affect the actual HTML attribute.

I've defined it so that it does.


On Thu, 2 Oct 2008, Tab Atkins Jr. wrote:
> 
> [There are cases where the placeholder definitely] can't be argued to be 
> a label.
> 
> Of course, it's still not in any way semantic.  The only difference 
> between "(optional)" being displayed near the input and being displayed 
> *within* the input is one of aesthetics.  The meaning of the document 
> isn't changed one iota.  This leans me even more toward a CSS solution.  

I don't see any harm to having this in the language really. We don't 
disallow UAs from rendering this after the control.


On Sat, 4 Oct 2008, Kristof Zelechovski wrote:
>
> What happens if a hint and a value are both specified?

On Sat, 4 Oct 2008, Tab Atkins Jr. wrote:
> 
> The value would display.  The hint only displays when the input is both 
> empty and not focussed.  @value negates the first condition.

On Sat, 4 Oct 2008, Kristof Zelechovski wrote:
>
> Does the hint display if the input control gets cleared after loading?
> 
> IMHO, The hint should not disappear on focus.  It should remain until a 
> new value is entered.

So specified.


On Sat, 4 Oct 2008, Nils Dagsson Moskopp wrote:
> 
> This is a BAD idea for consistency reasons - historically only selected 
> text disappears on input.

Well the exact details are up to the UA. Certainly following platform 
conventions is the best option.


On Thu, 23 Oct 2008, Andy Lyttle wrote:
> 
> It's *very* common to use the first <option> in a <select> as a 
> non-choice such as "Choose one...", setting the value to something 
> unique (often "" but it could be something else if "" is a valid choice) 
> so it can be treated as a non-selection.  This serves *precisely* the 
> same purpose as the placeholder attribute on text input fields, which I 
> had assumed wouldn't be valid for <select>.
> 
> I suggest that the placeholder attribute should indeed apply to 
> <select>, and the behavior should be similar to the current practice of 
> using the first <option>.  In particular, the placeholder should appear 
> both on the collapsed menu, and at the top of the open menu, although it 
> should not be selectable.
> 
> But the question is, when the menu is collapsed, when should the 
> placeholder be displayed instead of one of the options?  Any time the 
> value is ""?  Only until the user selects something?  Somebody smarter 
> than me, please figure this out. :-)

I've not made it apply to <select>, though it's an interesting idea. I'll 
revisit this later -- there's certainly a problem that we might want to 
solve around this issue.


[...snip lots of other feedback along the same lines...]

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'