- From: Johnny Stenback <jst@w3c.jstenback.com>
- Date: Tue, 06 Dec 2005 13:58:57 -0800
- 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 UTC