[whatwg] Placeholder option for text input boxes
dhtmlkitchen at gmail.com
Wed Oct 1 17:45:35 PDT 2008
On Wed, Oct 1, 2008 at 5:11 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Oct 1, 2008, at 10:27 AM, Aaron Boodman wrote:
>> On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski
>> <giecrilj at stegny.2a.pl> wrote:
>>> It is about how to write the feature detection code. This kind of code
>>> should be especially robust and relying on deprecated features does not
>>> it more so.
>> Ok, let's separate out the 'how people should program' part from the
>> 'what we will support part'. My opinion is that input.placeholder
>> should be supported, because it is consistent with how everything else
>> I don't think that most web developers even know that accessing
>> attributes as properties is deprecated, and would be surprised that
>> setting input.placeholder does nothing.
> We don't have a placeholder property in the interface for HTML <input>
> elements, but this is due to oversight and lack of subsequent demand. It was
> not meant to be a principled stand on the merits of DOM attributes.
> Personally I think using getAttribute and setAttribute for everything is a
> painful and error-prone coding style.
Other INPUT attributes work don't reflect.
Currently, input.setAttribute('placeholder', 'foo'), does update the
visual placeholder text. This is different than say the "value"
property of an input, which can be set, but won't change the attribute
input.value = "new";
input.getAttribute('value'); => "orig"
The way I would imagine |placeholder| would work (and imagining is
about all I can do at this point) is that |input.placeholder| would be
a DOM property. It wouldn't necessarily reflect the attribute
value; changing input.placeholder would not affect the actual HTML
input.getAttribute('placeholder') would return the attribute value as a string.
(in practice browsers return the value null for attributes not
present. Technically, getAttribute is "specified" to return a
domstring and null is not a string.)
For example of a non-reflecting property, we can look at the |checked|
property of a checkbox. The |checked| property does not reflect the
|checked| attribute. It's a good example of how a non-reflecting
|placeholder| property might work.
The result for the following example:
Safari 3, Firefox 3:
(did not test) - FWIRC, getAttribute('checked') will return the value
|false|, what happens after that, I do not know.
<input type="checkbox" checked="checked" id="c">
<input id="b" value='asdf'>
var d = document, c = d.getElementById('c');
var b = d.getElementById('b');
b.value = 1;
d.writeln("b.getAttribute('value'):..." + b.getAttribute('value'));
c.checked = false;
d.writeln("\nc.checked:................." + c.checked);
d.writeln("c.checked:................." + c.checked);
 HTML 5 - Reflecting content attributes in DOM attributes
Do we need a failing test for input.placeholder?
More information about the whatwg