W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2008

[whatwg] Placeholder option for text input boxes

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 30 Sep 2008 11:49:50 -0700
Message-ID: <c9e12660809301149v60af43eo92a916fb1ab178b3@mail.gmail.com>
---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, Sep 30, 2008 at 11:49 AM
Subject: Re: [whatwg] Placeholder option for text input boxes
To: "Tab Atkins Jr." <jackalmage at gmail.com>


On Tue, Sep 30, 2008 at 10:04 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle <whatwg at phroggy.com> wrote:
>>
>> On Sep 30, 2008, at 7:57 AM, 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.
>>
>> 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.
>
> Agreed.  Using @alt is a semantic hack.
>
> For the benefit of myself and others, I'm going to summarize the four
> current proposals.
>
> 1) @placeholder
>   Pro: Already implemented in one major browser.  Is opt-in, so doesn't


Partially implemented.

* 'placeholder' is not exposed as a DOM property.
* 'placeholder' is not implemented on TEXTAREA

For example, we can see a script which tries to get a 'placeholder'
property for an INPUT:

<!DOCTYPE html>
<html lang="en">
<head>
       <title>PlaceHolder</title>
</head>
<body>
<form action="">
 <input name="zip" placeholder="Zip Code">
</form>
<pre>
<script type="text/javascript">
var d = document, input = d.forms[0].elements[0];
d.writeln(input.name + ".placeholder=" + input.placeholder);
d.writeln(input.name + ".getAttributeNode('placeholder') =" +
input.getAttribute('placeholder'));
</script>
</pre>
</body>
</html>

Result:
Safari 3.1 (supports placeholder)
 zip.placeholder=undefined
 zip.getAttributeNode('placeholder') =Zip Code

Others (do not support placeholder)
 zip.placeholder=undefined
 zip.getAttributeNode('placeholder') =Zip Code

If a backwards-compatible degradation strategy is to be devised, it
should be as trivial as checking:-

if(!('placeholder' in input)) {
 createFallbackPlaceholder();
}

But this will fail in the current implementation in Safari 3.1.

input.getAttribute('placeholder') would not be degradable, as all
modern browsers would return the attribute value, regardless of
whether they support the actual placeholder behavior or not.

Are there any arguments against a |placeholder| property on INPUT?

Pros/cons for a |placeholder| property and attribute on TEXTAREA?

Garrett

> ~TJ
>
Received on Tuesday, 30 September 2008 11:49:50 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC