[whatwg] <input placeholder="">

[Ian Hickson]

On Mon, 17 Nov 2008, Ojan Vafai wrote:
> 
> This is a useful property on any text input element. Seems like it 
> should apply to textareas as well as contentEditable elements and 
> iframes with designMode on. I can point to real-world examples of the 
> latter if need be. I think it's acceptable that it be a plain-text 
> string in all cases, but that it ought to also be CSS styleable. I don't 
> know if html5 is the right place to spec that. WebKit currently uses the 
> input::-webkit-input-placeholder.

I think for contentEditable it's definitely not something we want to 
support natively; I've no idea how that would even work. I'd recommend 
doing it in CSS, using generated content based on the title="" attribute 
or some such.

For <textarea>, a placeholder value seems odd. Do you have examples of 
people doing that?


On Tue, 25 Nov 2008, Matthew Paul Thomas wrote:
> 
> I was asking, obviously, what use is a default value if you can't edit 
> it. If an enabled text field had a displayed value= but the value was 
> not actually editable, that would be unpleasantly surprising.
> 
> That problem applies just as much to <input placeholder="foo"> as it 
> would have done to <input value="foo" clearonfocus>: depending on 
> whether the placeholder text is greyed out, it would make the field 
> either look like it has a value when it actually doesn't, or look 
> disabled when it actually isn't. It would also hide the label or hint 
> for the field for *precisely* the period when you need it most. I'm not 
> aware of any possible presentation that avoids both (or even one of!) 
> those problems, and previously HTML5 has shied away from expecting 
> browsers to implement things that have no known reasonable presentation.
> 
> I appreciate that Web authors currently go to some scripting lengths to 
> position labels for text fields inside the fields, and I think it's 
> quite appropriate that they should have to go to those lengths, because 
> it makes bad design more difficult. I would rather see, as I've 
> previously suggested, markup for associating form controls with hints 
> outside them in a similar way as labels can be associated now.

I understand your position, but it seems that the industry has moved 
towards this as a pretty standard feature of user interfaces now, for 
better or worse.

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