W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005

Re: [dom3core] getAttribute

From: Johnny Stenback <jst@w3c.jstenback.com>
Date: Tue, 06 Dec 2005 13:58:57 -0800
Message-ID: <439609A1.4050203@w3c.jstenback.com>
To: www-dom@w3.org

Indeed. getAttribute() in IE is seemingly mapped to property getters on 
elements, i.e. element.foo === element.getAttribute("foo"). Given that, 
whether you get null or "" back from getAttribute() depends on the 
element and the attribute you're looking for. If the attribute is an 
attribute that's a string attribute, like say, 
document.body.getAttribute("bgcolor"), you'll get "" if the attribute is 
not defined, but if you do the same thing with "onunload" you'll get 
null back, since that's an event handler *property* which defaults to 
null in IE... Whether this ever changed in IE I don't know.

Brendan Eich wrote:
> 
>    Then, after adoption, IE unilaterally changed it,
> 
> 
> This is not so.  IE always implemented an odd mixture of nullable string 
> valued properties and non-nullable string-valued properties (which when 
> missing are returned as ""), and furthermore mapped properties to 
> attributes directly, via getAttribute.
> 
> So this has everything to do with backward compatibility going back to 
> IE 4.  The Mozilla experiment that you describe was much later, and 
> suffered the nullability confounder.  I just spoke with Johnny Stenback 
> about this and he said there may have been confusion when testing IE 
> between nullable and non-nullable attributes mapped from DOM JS properties.
> 
> /be
> 
> 
Received on Wednesday, 7 December 2005 06:38:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT