[whatwg] <input placeholder="">

[Matthew Paul Thomas]

On Nov 17, 2008, at 10:05 AM, Ian Hickson wrote:
> ...
> On Mon, 21 May 2007, Stijn Peeters wrote:
>> ...
>> 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 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.

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.

> ...
> On Tue, 30 Sep 2008, Andy Lyttle wrote:
> ...
>> 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 Thu, 2 Oct 2008, Tab Atkins Jr. wrote:
>> ...
>> 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.
> ...

But they couldn't really do that, it'd have all kinds of weird 
unexpected effects on pages designed by people using browsers that 
present it the way the spec suggests.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/