[whatwg] <input placeholder="">
Matthew Paul Thomas
mpt at myrealbox.com
Tue Nov 25 12:42:08 PST 2008
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
>> 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
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
>> (especially if their title string is too long to fit inside a small
> 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.
Matthew Paul Thomas
More information about the whatwg