Ajaxian

Friday, January 12th, 2007

Attribute Nightmare in IE

Category: IE

It’s Friday, so maybe you want to sit back for a few minutes and walk through some time in Tobie Langel’s life as he tries to get IE to play nice with attributes.

This tale walks through the pain of thinking that you have a working version, and then being disappointed again.

• IE: element.foo === element.getAttribute(‘foo’)
• iFlags to the rescue ? element.getAttribute(‘onclick’, 2);
• attributes collection: element.attributes[‘foo’];
• Maybe wait for Prototypes upcoming: readAttribute()

Posted by Dion Almaer at 9:21 am
5 Comments

4.2 rating from 21 votes

5 Comments »

Comments feed TrackBack URI

Jeez…now we’re all Ajax experts, do we not bother to read the underlying specifications? Just about everything Tobie describes can be ‘resolved’ by understanding the core DOM functionality. It’s one thing for him to post it, but does it then need to get picked up as gospel and promoted around the world!

For example, at the end of the post it says:

As mentioned in his below comment, Andrew found out in the meantime that some attributes could only to be accessed by their camelCased version (rowSpan, colSpan, dateTime, vAlign, etc.). Now, where does that come from ?

The implication is that on this, IE is quirky and non-conformant, but take a look in the W3C’s HTML DOM spec. See for example HTMLTableCellElement.

I’ve no axe to grind one way or the other about Microsoft, but I do find it annoying that the moment someone gets a problem in their code they talk about the bug-ridden and non-standard IE. In this case, the only thing you can find that is ‘odd’ is that in IE relative URLs are made absolute, which is why Tobie is having trouble with href and src. But the HTML 4.01 spec says that URLs must be made absolute, the problem is that it doesn’t say when this should happen. So although you might expect it to happen on navigation, there is nothing in the spec to say it should.

Other than that, the problems Tobie has had generally relate to not being familiar enough with the specs.

Regards,

Mark

Comment by Mark Birbeck — January 12, 2007

But the article mentions Prototype, so it MUST be posted on Ajaxian… :P

Comment by carter — January 12, 2007

Mark, I respectfully disagree. Though the spec gives camelCase versions of certain attributes, it does not prescribe whether those same values should be considered case-sensitive in get/setAttribute.

I’d argue that it makes no sense to insist on case-sensitivity, whether you’re operating in an HTML environment or an XHTML environment. In HTML attributes are treated as case-insensitive (so “maxLength” is the same as “maxlength” in your source code); in XHTML attributes must be lowercase (so “maxLength” is explicitly forbidden).

Furthermore, Tobie mentions several other areas where IE is unarguably nonconformant. Its getAttribute method reads from DOM properties (so, for instance, element.getAttribute(‘onclick’) would return a function instead of a string), yet its getAttributeNode method reads from attribute nodes. (And please show me where the DOM spec mandates a second argument to getAttribute.)

IE is by no means the only browser that fails to implement the DOM spec perfectly, but let’s be honest — its implementation is the poorest by far. We “understand” the core DOM functionality because we implement it in far-more-conformant browsers every day.

Comment by Andrew Dupont — January 12, 2007

Hi Mark,

Please refer to the Errata of DOM Level 2 specs which clearly states that:

The names of attributes defined in HTML 4.01 are also exposed as all lowercase, regardless of the character case used in the markup.

Regarding the href and src issues, the specs are also pretty clear:

The attribute’s effective value is determined as follows: if this attribute has been explicitly assigned any value, that value is the attribute’s effective value; […]

.

And more generally speaking, the fact that IE uses the @getAttribute@ method as a getter for the element’s property, rather than for the attribute node’s value, is just plain wrong.

Now, if you could kindly specify which other problems I described can be solved by being more familiar with DOM specs, maybe this discussion could be a bit more constructive and actualy help solve this issue.

Regards,

Tobie

Comment by Tobie Langel — January 13, 2007

I had some issue in the past developing our functional web testing tool InCisif.net in C# + IE Control. What i have noticed is an issue with the case of the attributes. I am reading let us say the attribute name of a DIV. But the attribute name is spelled this way in the HTML: ‘nAme’. I use reflection to read the attribute name spelled ‘name’ in the C# code, the first time everything is case insensitive it is working. My reflection code is set with BindingFlags.IgnoreCase. I open other pages, click on other controls. Do I do not know what… I go back to the first page and try the same code when I try to read attribute name via reflection there is a Exception ‘Member not found’, if I pass ‘nAme’ then I can read the value.
For me getAttribute(“name”,0) is working ok. I really care about what is in the DOM.
What ever it is there is something weird with the case of attribute.

Frederic Torres
http://www.InCisif.net
Web Testing with C# or VB.NET

Comment by Frederic Torres — March 9, 2007