Tobie Langel

Comments

• 

  Andrew Dupont says:

  I made another leap forward a few hours ago: some of the properties (rowspan, colspan, datetime, valign, etc.) need you to feed camelCase versions (rowSpan, colSpan, dateTime, vAlign) to getAttribute in order to get the proper value. Yes, this is fucking ridiculous.

  Luckily, there are precious few attributes that need this, so I just built a translation table.

  Thu, January 11 at 13:51 PM

• 

  Stephen Stchur says:

  (sigh)... just more of IE’s never-ending quest to make the web completely and totally unmanageable in every way.

  Nice blog entry though… I’ll file this away for when I (inevitably) run into this issue myself sometime down the road.

  Thu, January 11 at 22:29 PM

• 

  Tobie Langel says:

  [...] I’ll file this away for when I (inevitably) run into this issue myself sometime down the road.

  You could also use Prototype’s upcomming readAttribute method and stop worrying about it! ;-)

  Fri, January 12 at 01:31 AM

• 

  Marty says:

  I Love you guys! This has baffled me on more than one occaision, but is the first time I’ve ever heard of getAttribute(‘foo’,2), which would have saved my day, had i known about it.

  You guys have access to top-secret documentation us mere mortals can’t get to on msdn?

  Fri, January 12 at 12:57 PM

• 

  Mark Birbeck says:

  Hi,

  I’m intrigued to know why you think that your “well-behaved” browsers are doing the right thing? Do you have any references for that? If you read the DOM 1 specs, you’ll see that attributes are pretty much regarded as ‘live’. Did you not wonder why there was a setAttribute function, if getAttribute was always supposed to return the value that was set in the initial document? :)

  Also, if you look at the DOM specs you’ll see that the use of camel case to locate an attribute whose name is not camel case is quite common. I don’t say it’s good…but you’ll see in the spec that there are things like tabIndex and accessKey.

  So, if we assume that attributes are meant to be live, and that camel case is a quirk (but it’s not Microsoft’s quirk), then you are still left with the interesting question of whether the relative path in href should have been converted to an absolute one (which is really what you are seeing).

  Looking again at the specifications it does say that relative paths are made absolute based on the document URL (or any base element) but interestingly it doesn’t say when to do that normalisation. I certainly always assumed it happened on navigation, but your experiments show it happens earlier. I can see why one might implement it that way, and there are certainly situations where it would be useful to have all URLs ‘normalised’. But I don’t think you can say it’s a bug, or a ‘bad’ implementation, when the spec itself is quite vague.

  In short…I sympathise with the fact that you’ve been having problems, but it’s clearly not true (at least in this case) that ‘in IE everything is broken’.

  Regards,

  Mark

  Fri, January 12 at 13:41 PM

• 

  Mark Birbeck 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 ?

  From the W3C’s HTML DOM spec. See for example HTMLTableCellElement

  Fri, January 12 at 13:54 PM

• 

  Andrew Dupont says:

  Mark, see the reply I made on Ajaxian: http://ajaxian.com/archives/attribute-nightmare-in-ie#comment-246047

  Fri, January 12 at 20:30 PM

• 

  AKS says:

  Gentlemen! Stop to support this browser! Or cease to complain! Be strong – choose one way to go!

  Sat, January 13 at 01:33 AM

• 

  Wiktor says:

  Opera has a weird behaviour when you use getAttribute for “action” attibute. It returns an absolute url instead of the attribute as set in the document.

  http://spacergif.net/2006/07/13/opera-getattributeaction-bug/

  Sat, January 13 at 07:52 AM

• 

  Tobie Langel says:

  @ Marty: Nope, this documentation is available right here.

  @ Mark: Thanks for your extended comment.

  The DOM specs clearly specify that getAttribute should return:

  The Attr value as a string, or the empty string if that attribute does not have a specified or default value.

  Clearly, when IE returns a function for getAttribute('onclick') it is not conforming with the specs.

  Furthermore (from the Attr Interface definition, right above:

  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; [...]

  This also clearly implies that if the value of the href attribute has been set to a relative path, it is that relative path that should be returned.

  As Andrew mentioned in his comment on ajaxian.com, and as clearly stated in the Errata of DOM Level 2 specs:

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

  Furthermore – and that is where IE gets it really wrong – getAttribute is a getter for the attribute node’s value, not for the element’s property.

  @ AKS: You are probably right about the complaining part. I hope that this article does not only sound as some IE bashing but also provides some valuable information to developers encountering similar issues. Marty’s comment above seems to indicate so.

  Wiktor: Opera, prior to version 9, was returning absolute paths. They changed that in version 9 for @href, but for some reason, forgot about src... and action.

  Sat, January 13 at 14:13 PM

• 

  Scott says:

  I’m working on a Javascript library. I use Element.getAttributeNode to access the attribute I want on the given element. I found that was the only way I could reliably get the attributes in every browser I was targeting (IE 6+, FF 1.5+, Safari 2.0+). Would that work in this situation?

  Sun, January 14 at 00:22 AM

• 

  Tobie Langel says:

  Hi Scott,

  If I’m not mistaking, in IE6, getAttributeNode is just a getter for the attributes collection I described above and therefore suffers from the same flaws.

  Sun, January 14 at 01:40 AM

• 

  AKS says:

  @Tobie Langel

  Marty’s comment above seems to indicate so (i.e. article provides some valuable information to developers). It indicates that some developers neglect reading the MSDN Library documentation. If we wish to work effectively with IE, we should know its specific features from the primary source. I wish to notice, that all of us would like to have one standard. Because we are lazy and we hate to write for each browser separately. BUT MS team is lazy too – they won’t create new engine. And we should accept it, as due.

  Sun, January 14 at 04:33 AM

• 

  Tobie Langel says:

  AKS: Well, unfortunately we cannot… as it’s not an open source program! ;-)

  And unfortunately, reading IE’s documentation is not sufficient, as it is often incomplete and sometimes even wrong.

  Sun, January 14 at 10:28 AM

• 

  AKS says:

  “accept it” means just a state of affairs.

  ...sometimes even wrong.

  It would be interesting to get into details.

  Sun, January 14 at 11:16 AM

• 

  Tobie Langel says:

  Well, for example and as I mentioned above, IE docs claim that when the iFlag is set to the integer 2, the getAttribute() method returns “the value exactly as it was set in script or in the source document.” Testing prooved that to be a false claim.

  Sun, January 14 at 12:30 PM

• 

  AKS says:

  document.body.getAttribute(‘onload’, 2); // -> “undefined” in IE

  Remarks from MSDN Library: “The onload attribute of the body object sets an onload event handler for the window.”

  document.body.getAttribute(‘onload’); // -> “function anonymous(){...}” in IE

  That’s his own way to parsing of intrinsic event scripts. But we have an opportunity to take advantage of the attributes collection (you mentioned it). Of course, this all is inconvenient enough. But who has told, what will be easy? ;) We must remember – there’s no hope for indulgence from IE. And that’s why I wrote my first message.

  Sun, January 14 at 14:42 PM

• 

  Tobie Langel says:

  AKS: Don’t confuse, as IE does, an element’s JavaScript property with an element’s DOM attribute. These are two different things.

  Sun, January 14 at 23:54 PM

• 

  AKS says:

  These are two different things.

  I talk about:

  
      <body onload='alert("body.onload")'>
      <script type='text/javascript'>
          window.onload = function () {
              alert('window.onload');
          }
      </script>
  
  
  

  Is it different things? May be in Opera…

  Mon, January 15 at 00:38 AM

• 

  Tobie Langel says:

  AKS, which attribute you are talking about doesn’t really matter. As getAttribute is a DOM method, it is supposed to query the DOM, not the element’s JavaScript properties. Firefox, Opera and Safari behave correctly in that aspect. IE doesn’t.

  In the example you give above,

  document.body.getAttribute('onload');

  should return:

  // 'alert("body.onload")'

  That is the correct, standard compliant behavior.

  Anything else is wrong!

  Mon, January 15 at 04:26 AM

• 

  Alex Tarelkin says:

  To be more accurate you should check attribute existance with hasAttribute() and do not rely upon JavaScript type casting when outputting element.getAttribute(). element.getAttribute() should return a Node object with nodeType=2 or null (‘undefined’ in case of IE) otherwise.

  Mon, January 15 at 11:54 AM

• 

  Tobie Langel says:

  Alex: unfortunately, IE does not support hasAttribute. But that’s something that has also been fixed in Prototype’s up and comming release. Stay tuned.

  Regarding what getAttribute is supposed to return, this is an interesting issue.

  If you read the specs, getAttribute should always return a string, whether it has been specified or not. But since main browsers haven’t ever followed that spec, backing out of it is now impossible as it would break thousands of websites.

  Opera 8, who was returning an empty string rather than null in version 8, switched to returning null on unspecified attributes in version 9.

  Mon, January 15 at 16:55 PM

• 

  Alex Tarelkin says:

  Hm, it is interesting. Guys, you opened my eyes. Thanks. I have belived getAttribute(‘something’) should return the same as @something XPath expression. Now I see that there is getAttributeNode for that. I should have more thouroghly looked throught the spec.

  Tue, January 16 at 05:28 AM

• 

  asaris says:

  This is one of the reason why I develop web pages based on W3 standards for internal use of companies. It works great in all browsers except IE. I’m forced to support IE for public web pages. It slows down development. I would like to forget IE exists, but it exists while users still use it.

  Wed, January 17 at 10:18 AM

• 

  Supak says:

  I honestly believe that anyone defending IE is on Microsoft’s payroll, or a masochist that likes working double the time necessary…thanks for this article.

  Wed, February 07 at 05:40 AM

• 

  Leo says:

  I agree with Supak, and if anyone tried to do cross-browser ajax application from scratch without using any javascript libraries, knows the pain! I might be wrong but Firefox has (or had) some issues with element.name property … use element.getAttribute(“name”) instead …

  btw it’s a very useful article for ajax developers, thnx

  Thu, February 15 at 09:08 AM

• 

  Tobie Langel says:

  Alex, Supak & Leo: Thanks for the nice comments. Glad to hear this has been helpful!

  Leo, nice tip! I’ll look into this as soon as I have a minute.

  Fri, February 16 at 01:40 AM

• 

  DigitaLink says:

  I just ran into the IE getAttribute issue in a little script I was hobbling together to dynamically add a little ‘open in new window’ icon to external links. Works perfectly in every browser … except IE. Oh well. IE users don’t get the little icon. No biggie really.

  Here’s my take on IE these days. It’s the new NS4.xx. I will only do the bare minimum necessary to preserve page function and layout with IE. Anything fancy or extra must work in Firefox/Opera/Konqueror (no Mac, can’t test Safari, Konq is as close as I can get) and degrade to a basic form in IE. Then again, I have the liberty of being able to take that stand. Some of you don’t. For you, I will say a prayer for an easy solution one day. Like an IE extension that will flip out the Trident engine for Gecko. :D

  Tue, February 20 at 13:30 PM

• 

  mark says:

  hi, i need to manually execute the code contained in an onload event,

  i.e. eval(element.getAttribute(‘onload’));

  This works in Firefox, but like you mention, IE returns an anonymous function. How can I therefor get it to execute that function? I tried using

  return(element.getAttribute(‘onload’));

  but that didn’t work. Any ideas?

  Thanks! helpful post.

  Thu, March 01 at 01:04 AM

• 

  Tobie Langel says:

  Hi Mark,

  I’d try something like this:

  var attr = element.getAttribute(‘onload’);
  typeof attr == 'function' ? attr() : eval(attr);

  Thu, March 01 at 03:12 AM

• 

  Mark says:

  Thanks Tobie this really helped. I actually took that snippet of code you sent and created a simple html file with it and saw that it worked. Then, I tried it with the application I need it for and it didn’t work – I therefore knew something else was wrong. I dug down and found that the html editor on the page (xinha) was overwriting the original body.onload code with: window.onload = xinha_init. argh!!!!!

  Anyway, thanks for indirectly pointing me in the right direction, it led me to the root of the problem.

  Nice site btw.

  Fri, March 02 at 14:20 PM

• 

  Frederic Torres says:

  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.

  Fri, March 09 at 01:09 AM

• 

  Keith Alexander says:

  I laughed, I cried, I cried some more. Thanks for documenting this.

  Tue, March 27 at 14:22 PM

Comments are closed