24 Bottles Of Beer
moz-behaviors.xml has had a small update. In previous versions I was honouring an Internet Explorer bug that meant updating a DOM property also updated the corresponding attribute. This is a subtle bug and requires some explanation.
Consider the following code snippet:
document.body.foo = "bar";
alert(document.body.getAttribute("foo"));
In standards compliant browsers the alert box will show “null”. Internet Explorer shows “bar”. The reason for this behaviour is that IE makes no distinction between DOM properties and attributes. This is illustrated even more clearly by the following code:
document.body.setAttribute("class", "foo")
alert(document.body.className);
There is a school of thought that says the IE behaviour is more intuitive. I tend to agree. I can’t think of a good reason why DOM properties and attributes have been separated like this (the className example is clearly a bug however).
So what does this have to do with beer? Well, nothing really. I just wanted to thank the good guys at Technical Pursuit for sending me some beer. They’ve been using moz-behaviors quite a lot and decided to thank me in a way they knew I’d appreciate. For the record, If anyone else wants to send me beer that is completely OK.
Comments (8)
Leave a comment
Comment: #1
Dean, are you sure document.body.foo setting an attribute is a standards compliance error? Certainly no standard says you have to do it, but I’m not so sure there’s anything anywhere that says you can’t.
Sorry, I’m not going to send you beer though, one day I’ll buy you a beer, you just need to be in the same pub…
Comment: #2
Jim, no I’m not 100% sure. I can’t find two browsers that behave the same way. But according to a conversation in an old weblog post, the Mozilla behaviour is correct:
https://bugzilla.mozilla.org/show_bug.cgi?id=295657
Comment: #3
The above bug was rejected BTW. Dave Baron’s last comment seems to suggest that the HTML and DOM specs are not too clear about this subject. If someone else can throw more light on it I would be grateful.
Comment: #4
Well my reading of HTML DOM 2 says it’s allowable:
See 1.6.1: “HTML attributes are exposed as properties on the element object” so that’s cool, but then it goes:
“The attributes are exposed as properties for compatibility with DOM Level 0. This usage is deprecated because it can not be generalized to all possible attribute names for XML. We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes.” (my emphasis)
So, to me it’s reasonably clear that it’s allowable. I have conceptual problems too of why a DOM interface would not change the D, which is perhaps why it was so obvious to the framers that they just forgot. Still we have a problem ever getting a request from the WG to clarify it, and Moz spec have obviously made their decision, we won’t change it. I don’t think it’s fair to typify another choice as non-conformant though, IE has enough genuine violations.
Comment: #5
Thanks for following up on my forum question, Dean. But I am not sure what you want to tell us.
You wrote: “the className example is clearly a bug however” The className example works the same in IE, Firefox and Opera. The alert shows “foo”. The two-way connection between attribute and property is there for any HTML-DTD-defined attribute, AFAIK. And setting the attributes through the properties works better than the bug-ridden set/getAttribute implementations (in IE). Taking the pragmatic point of view, what is the bug you refer to? I am confused.
Or is it about the fact that the connection between attribute and property should not be there at all? Or that if it is there, that it should be for any property, which IE does, but Mozilla does not?
Comment: #6
Martin.
The DOM HTML 2 spec is a little dodgy, the problem comes with the default form values, they suggest that el.value is inconsistent with the attribute value. Mozilla have chosen this to mean that all .property is inconsistent with property, I beleive this is wrong, and believe 1.6.1 is clear on the fact, so the .className is a bug in mozilla. However there’s little we can really do unless we can get the DOM WG themselves to clarify, Moz’s interpretation is not completely outrageous. I do think though consistency with other implementations would be advantageous but I’m suspecting the required special casing of defaultValue wouldn’t be that desirable in the codebase.
See the bug linked above, and the DOM HTML 2 specification.
Cheers,
Comment: #7
This IE bug have another annoying effect. If form has input with name attribute set to “name” then even form.getAttribute(‘name’) returns this input and it is impossible to get name attribute of form.
Comment: #8
Attribute and property are two different thing, e.g. given the following code:
<a id="something" href="/path/to/something">Something</a></p>document.getElementById(“something”).getAttribute( “href” ) gives /path/to/something; while document.getElementById(“something”).href gives http://www.example.com/path/to/something
Changing value of attribute/property may change its counterpart, but this is not always the same (especially the form elements).
Comments are closed.