weird getAttribute() in Moz

element.JSValue != element.DOMAttributeValue

for lack of any better way of stating it.

<input type="text" value="hello world">

...

input.value = "goodbye cruel world";
input.getAttribute("value") == "hello world"


Just because IE (incorrectly) maps attribute names to HTML DOM properties doesn't mean that is the way it should be. (And yes, the behavior you see in Firefox is the correct behavior per DOM specifications.)


As for your "counterexample", you just set the attribute to the correct this.value property. Of course you'll get the correct value back afterwards when you getAttribute. :)

that means that

object['myattribute'] is not the same with object.getAttribute('myattribute')?

But why only if reading the attribute?

isn't JSON compatible with DOM?

that means that

object['myattribute'] is not the same with object.getAttribute('myattribute')?
Indead that is what it means. See the spec: value of type DOMString

When the type attribute of the element has the value "text", "file" or "password", this represents the current contents of the corresponding form control, in an interactive user agent. Changing this attribute changes the contents of the form control, but does not change the value of the HTML value attribute of the element. When the type attribute of the element has the value "button", "hidden", "submit", "reset", "image", "checkbox" or "radio", this represents the HTML value attribute of the element. See the value attribute definition in HTML 4.01. [emphasis mine]

But why only if reading the attribute?The form control value is set to the HTML attribute value when parsing. But the HTML attribute value isn't changed when the control value is changed. The DOM property value corresponds to the control value, not the HTML attribute value.

isn't JSON compatible with DOM?JSON is neither compatible nor incompatible in nature. They are not the same thing, and JSON doesn't naturally perform the same functions as the DOM. You must realise that JSON is all about JavaScript objects, and DOM is all about mapping HTML/XML to any programming language. DOM has a natural distinction between a lot of things that JSON doesn't have any built ins for, because JavaScript doesn't have the distinction.

that's clear now. Thanks jkd an liorean, I got it now. The form control value is not the same as the DOM's attribute "value" getting. Darn :rolleyes: Will we ever have a steady, stabile, common javascript language? :cool:

Will we ever have a steady, stabile, common javascript language? :cool:I hope not. Really, stagnation is death, JavaScript needs to evolve. And anyways, this isn't JavaScript, it's DOM, so it doesn't really have any direct connection with whether the language is steady, stabile, common.


The core language is quite stable by now, by the way. You'll have to try some screwball cases to see where implementations are incompatible. Something like this for instance:var
a=[0,,2,,,5,,],
i,
b=[];
for(i in a)
b.push(i);
alert(['a.length: '+a.length,
'a: ['+a+']',
'enum of a: '+b].join('\n'));The result will be different in iew, moz and op/saf. In this specific case, op/saf are the correct ones. The results are as follows in the different browsers: iew op/saf moz
---- ---- ----
a.length 8 7 7
a [0,,2,,,5,,] [0,,2,,,5,] [0,,2,,,5,]
enum of a 0,2,5 0,2,5 0,1,2,3,4,5,6

stable is now, probably due to the ECMA and W3C efforts. But I would like, same as server-side are, to do the same thing (according to the variants, while evolving) nomatter the browser. Evolving is one thing, stubborness is another one. I am not talking about NS4/IE3 against Moz/IE6 , am am talking mainly about Moznow against IE 6/7 . The present browsers act different, their interpretors are different, sometimes none of them follow not even W3C recom's or full ECMA... This is sometime frustrating. I reckon things have improved last say 5 years, but still is ennoying to check on all the main browsers (not only javascript, but even HTML or CSS codes) on and on and on and on ;)