[whatwg] <input placeholder="">

[Tab Atkins Jr.]

On Tue, Nov 25, 2008 at 2:42 PM, Matthew Paul Thomas <mpt at myrealbox.com>wrote:

> 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.


I'm still as confused as Ian here.  This isn't a default value.  You use
@value for that.  @placeholder can represent a *sample* value, but that is
*not* intended to be submitted, and has no need to be editted.  It's never
expected to be directly useful, but rather just to show the user directly
what is expected in the field.

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.


Actually, due to the prevalance of this sort of thing, most people are
rather used to gray (and possible italicized) text in an input disappearing
when they click into it.  It doesn't confuse them at all.

The fact that it *is* relatively widely used, and isn't confusing to the
average person, means that the suggested presentation *is* useful.

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.


Actually, it's really not any great length at all.  For example,
http://www.kryogenix.org/code/browser/labelify/ is a dead-simple jQuery
plugin that does it automagically for you.  There are several other variants
on the theme (this is just the first I found in a quick search), and I'm
certain other js libraries have similar things built for them.

The problem, of course, is that alternative display devices which try to run
javascript but display pages or handle user interaction substantially
differently may get an extremely messed up result out of any js-based
solution.  By building it directly into the language the UA can decide
precisely how it wants to render and control this sort of thing to be
maximally useful to its users.


>  ...
>> 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.
>

This is true, at least for the standard desktop browsers.  They'll all
standardize on the standard gray text that's already in use, because that's
what users are used to and expect.

I still greatly prefer a CSS-based solution over this, but I can live with
it.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081125/7fd1b78d/attachment.htm>