On Wed, Oct 1, 2008 at 5:11 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Oct 1, 2008, at 10:27 AM, Aaron Boodman wrote:
>
>> On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Please. This thread is not abort how to write JavaScript code in
>>> general.
>>> 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
>>> make
>>> 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
>> works.
>>
>> 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
value:
<input value="orig">
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[1] the attribute
value; changing input.placeholder would not affect the actual HTML
attribute.
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:
b.getAttribute('value'):...asdf
c.checked:.................false
c.getAttribute('checked'): checked
c.setAttribute('checked', 'checked');
c.checked:.................false
Opera 9.5,
b.getAttribute('value'):...asdf
c.checked:.................false
c.getAttribute('checked'): checked
c.setAttribute('checked', 'checked');
c.checked:.................true
IE:
(did not test) - FWIRC, getAttribute('checked') will return the value
|false|, what happens after that, I do not know.
<!DOCTYPE html>
<html lang="en">
<head>
<title>CHeckbox-attribute.html</title>
</head>
<body>
<form action="">
<input type="checkbox" checked="checked" id="c">
<input id="b" value='asdf'>
</form>
<pre>
<script type="text/javascript">
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.getAttribute('checked'): "+c.getAttribute('checked'));
d.writeln("c.setAttribute('checked', 'checked');");
c.setAttribute('checked', 'checked');
d.writeln("c.checked:................." + c.checked);
</script>
</pre>
</body>
</html>
[1] HTML 5 - Reflecting content attributes in DOM attributes
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#reflect
Do we need a failing test for input.placeholder?
Garrett
> Regards,
> Maciej
>
>
