- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 17 Nov 2008 10:05:47 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 17 November 2008 02:05:47 UTC