Arguments

name (DOMString) required

The name of the attribute to retrieve.

Description

Get the value of an attribute with the specified name.

This method is for working with non-namespaced attributes; to get a namespaced attribute, use the DOM 2 getAttributeNS method instead.

Return value

The attribute value; if the attribute is not defined this method should return an empty string, however most browsers return null (see Compatibility notes above).

Compatibility

Firefox, Safari and Opera return null for attributes which are not defined. They should return an empty string, but returning null is a de-facto convention (in fact earlier versions of Opera did return an empty string, but then changed to null to match this convention). Nevertheless, this behavior is considered a bug.

if(!node.getAttribute('whatever'))

Internet Explorer, Firefox, Safari and Opera 9.5 do not match attributes which are not explicitly defined but have a specific default value in this document type, such as the shape attribute of an <a> element (only Opera 9.0 gets this right).

Opera 9.0 returns an interpreted value for a style attribute, rather than the literal value. For example, this value in HTML:

style="color:green;font-size:1.5em;position:fakevalue;left:.5ex;"

gives this value from getAttribute:

color: #008000; font-size: 1.50em; left: 0.50ex;

You can see how several changes are evident — the color value has been interpreted to hexadecimal, the font-size and left values have been normalized with leading and trailing zeros, and the fake value (for which read: value it doesn't understand) has been removed. A space has also been inserted after each colon and semi-colon.

Firefox has similar, but less aggressive, behavior — leading zeros are added to float values which begin with a dot, non-understood values are removed, and a space is added after each colon and semi-colon; but float values are not otherwise normalized and colors are not interpreted.

Internet Explorer in HTML retrieving a static href attribute from a a element returns a fully-qualified URI, rather than the literal attribute value. (For a link element it correctly returns the literal value.) IE also returns a qualified URI for a static src attribute from a img element. However its behavior is different when retrieving dynamically-created attributes — see setAttribute for details.

When retrieving a style attribute, IE returns a style object, rather than an attribute value; retrieving an event-handling attribute such as onclick, it returns the contents of the event handler wrapped in an anonymous function; retrieving an attribute value which evaluates to boolean true (such as disabled or checked, when defined) or a number (such as tabindex), it returns a boolean or number (respectively), rather than a string. Since these attributes are considered by IE to have non-string values, if they're not defined they return null rather than an empty string; IE also returns null for non-defined attributes it doesn't recognise (ie. custom attribute names); other non-defined but known attributes correctly return an empty string.

To retrieve a class attribute you must refer to it as className; to retrieve a for attribute you must refer to it as htmlFor:

//these work in IE, null in others
element.getAttribute('className');
element.getAttribute('htmlFor');

This is a side-effect of the mapping of attributes to HTML DOM properties — for example, as a DOM property you always have to refer to element.className rather than element.class, because class is a reserved word¹ in JavaScript. But while other browsers reconcile this by allowing string values to getAttribute to use the original attribute name, Internet Explorer does not:

//these work in others, null in IE
element.getAttribute('class');
element.getAttribute('for');

Furthermore [yeah I know, my brain is melting too] there are other attributes that can only be referred to by the camel-cased name they use for their DOM property equivalent, even though those names are not reserved words; examples of this are tabIndex, accessKey and useMap, and all table-specific attribute properties like colSpan and rowSpan.

And still there's more ...

Internet Explorer implements a second argument to getAttribute, which is supposed to control the way it behaves. The second argument is a numerical flag that can take the value 0, 1 or 2. According to MSDN:

• 0 (default): Performs a property search that is not case-sensitive, and returns an interpolated value if the property is found.
• 1: Performs a case-sensitive property search.
• 2: Returns the value exactly as it was set in script or in the source document.

The difference between 0 and 1 appears to be implemented as documented — attribute names are treated as case-sensitive, so a search for onClick will not match onclick. However the value 2 does not behave as documented — event-handling attributes are still returned as functions, the style attribute is now an empty string, and values which evaluate to boolean true now return 65535.² On a more positive note, href and src attributes will now return their literal value, rather than a qualified URI. Using this second argument does not affect any other browser.

Internet Explorer in XML is a whole different kettle of fish. There are no property mappings there, so all of this errant behavior simply doesn't apply — getAttribute is a getter for Attr node values, as it should be, and behaves according to specification, with the single exception (that is the exception for all browsers) that attributes which are not defined return null rather than an empty string.