For attributes, I generally use the property if it's available and otherwise the GSetAttribute methods. Properties have the advantage that you get e.g. absolute link uris instead of an relative link in the DOM.
When I'm just about to store some random data, I'll always use, which won't pollute the DOM with invalid markup and doesn't limit me to strings.

steve said on May 24, 2007

I always prefer foo.setAttribute(), since it is *SUPPOSED* to be a cross-browser supported call... as is anything that calls this outside of the browser world... e.g. Java doing DOM manipulations.

that said, IE's support for this, is lackluster at best... so I've build stuff to fix IE to behave...


.setAttribute('class', '...');
.setAttribute('className', '...');

.setAttribute('for', '...');
.setAttribute('htmlFor', '...');

however, if in my code I'm already in the "fixing IE's silly bugs" mode... I may break down and just do... = 0;//IE is picky about the case of this attribute... ugh...

Richard Rutter said on May 24, 2007

I prefer element.attribute cos it's simpler and how I used to do it back in the old DOM 0 days. But I actually use element.setAttribute as it's 'proper DOM' and so may have more longevity. Apart from setting classes when I use element.className because that works for IE.

Nate Klaiber said on May 24, 2007

I use the get/setAttribute. Makes my conscience feel better.

Jeff Smith said on May 24, 2007

I also use get/setAttribute as it's just what I'm used to, and not for really any other reason.

Andrew said on May 24, 2007

I was using element.get/setAttribute() but it just seemed to be a long way round for something that was supported fine by using element.attribute. I didn't consider that one was the correct DOM way and one not; although I usually do.

I think the better question is: if they get rid of one, which can you live without? element.attribute seems more in tune with OOP so I would prefer to keep that one.

David Martin said on May 24, 2007

I believe that get/setAttribute is the correct way. That being said, I have ran into Internet Explorer not honoring all attributes correctly in this manner. For instance, try setting the onClick attribute using setAttribute. If I remember correctly, you'll run into some issues.

Daniel F. said on May 24, 2007

I use element.setAttribute(name, value) and I think this is the right way. But sometimes you dona€?t have that choise, especially when youa€?re coding for IE.

Have you ever tried to add an additional Eventhandler to the existing Eventhandlers of a body attribute like "onload"? It took me hours! Firefox and Opera allow to concatenate these function calls. IE dona€?t. Now I know that therea€?s a function called addEventListener() that is specified in W3C DOM and works well.

Brendon Kozlowski said on May 24, 2007

getAttribute() and setAttribute()

I don't necessarily feel one is more "correct" than the other, but I do prefer to use the DOM methods whenever possible.

Tobie Langel said on May 24, 2007

That's an interesting question. IMHO, it arises solely because of one issue, IE's failure to distinguish between attributes of a DOM node and properties of a JavaScript object.

Technically, these two things are different. For some reason, IE got them mixed up. (I wrote an article about that a while ago).

That's why we had to implement readAttribute and writeAttribute DOM methods in Prototype (the latter is not included in a stable release as for now).

Honestly, this is typically a situation where I'd favor using a library over using your own code. We went over tremendous testing efforts to ensure these methods were fully compatible in IE, Opera, Firefox and Safari, and trust me, it was a pain!

Ara Pehlivanian said on May 24, 2007

element.attribute, but I think there's one or two places where you need to use setAttribute() though I can't remember off the top of my head.

BTW, I think it's: mylink.setAttribute('src', '/path/to/image.gif');

Rory Fitzpatrick said on May 24, 2007

I use a library and let it take care of it....

Mark Wubben said on May 24, 2007

So what IE does is translate any calls to setAttribute into property setters, or in code:

node.setAttribute("width", "100")


node.width = "100"; 

When writing IE only code (my work project at the moment) I tend to go for the property, otherwise I prefer to use setAttribute.

Tim McCormack said on May 24, 2007

I'm with Tobie: Using element.attribute just causes problems with javascript's object properties.

Rick said on May 24, 2007

I prefer to use element.attribute for quick and dirty work, but sometimes the setAttribute and getAttribute methods are necessary. When you're using custom attributes for example.

Eric Webster said on May 24, 2007

answer.setAttribute("choice", "b")

molily said on May 24, 2007

Brendon said: ??I do prefer to use the DOM methods whenever possible??

It's a common misunderstanding that element.get/setAttribute is part of the official DOM and element.attribute is kind of proprietary. That's not entirely right. get/setAttribute is part of basic DOM Core which applies to all XML/SGML-style documents, (X)HTML amongst others. element.attribute is also standardized in DOM HTML, the special, additional DOM for (X)HTML documents.

We're using the special DOM HTML features all the time (e.g. document.body), they're handy, shorter and often faster (compare this to the DOM Core way: document.getElementsByTagName["body"].item(0)). Thus, I think it's okay to use the special DOM whenever it's possible. If it isn't (for example when dealing with non-(X)HTML nodes), fall back to DOM Core. But both techniques are officially standardized.

nuffGigs said on May 24, 2007

I use element.attribute="value";

I never had a reason to switch to get/setAttribute.

Riddle said on May 24, 2007

If I know that I can write 100% standards compliant code (for example Greasemonkey's UserJS), I use proper DOM - set/getAttribute. For industrial use I choose HTML shorthands because they're supported everywhere (try setting class in IE. ;)

Mark Wubben said on May 24, 2007

Accidentally, because of IE's mapping of attributes to properties you can't use setAttribute("class") or getAttribute("for"). When mapped to properties these attributes are JavaScript keywords, and will therefore cause syntax errors.

Andy Kant said on May 24, 2007

I usually use the element.attribute method, it might not be the *proper* way, but using mutators is just so against the general JavaScript coding style that I prefer to avoid it. I like to stay consistent with my coding style whenever possible. If I have problems with using the hash, I'll revert back to the mutators.

Miha Hribar said on May 24, 2007

DOM, for no real reason. Perhaps because it just looks complicated :)

Bramus! said on May 25, 2007

Using elem.attr = val; here as JS doesn't really have public/private datamembers on those objects (not to speak about crossbrowser compatibility). Would be nice though it there were, then we would be forced to use accessors ("getters") and mutators ("setters") making it all a wee bit more consistent with other scripting languages ...

Jake Archibald said on May 25, 2007

In an ideal world, I'd use element.attribute when I'm wanting an attribute of the javascript object and element.getAttribute() when I'm wanting the value of an attribute node within the element.

The difference is noticeable in cases such as a src of an image, where getAttribute *should* return the content of the attribute src, whereas element.src returns the full path to the image.

Having said all that, 99% of the time I use element.attribute as it presents the least cross-browser issues.

RStankov said on May 25, 2007

I use get/set Attribute() because I have had problems with some sites with element.attribute. But for some occasions, like forms (element.value) or some specific attributes(className, id) is better to use direct link.

p.s. and element.getAttribute('style') have a lot difference !

Luke said on May 25, 2007


If I've decorated the element with custom attributes in the markup, I use (g|s)etAttribute for those attributes.

Jesse Skinner said on May 25, 2007

I've always used element.attribute. I find it more readable, I've never ran into a problem with it, and I don't foresee a day when a browser won't support it.

Tadeusz Szewczyk said on May 26, 2007

I always prefer the clean DOM version. You can nevertheless merge those two creating a function of your own if you want.

Christoph Hautzinger said on May 28, 2007

i use the getter/setter if i created the attribute for myself i want to manipulate.
and the direct access if it's a real html element-attribute as defined by w3c.

Montoya said on May 29, 2007

I use the second because it behaves like a proper object method, which is natural to me since I learned object oriented programming as a practice.

ppk said on May 30, 2007


My general rule is: never use setAttribute and getAttribute when you can avoid them. There are just too many things wrong with their implementation. That said, I must admit that img.setAttribute('src','value') seems to have no bugs ... yet.

Anne van Kesteren said on May 30, 2007

Note that element.attribute only works if the element (well, object) exposes an interface that has that attribute as member. This will not be the case for arbitrary XML nodes for instance or unknown attributes.

Koen Eelen said on May 30, 2007

I always use element.attribute, but when I add an non-valid attribute to a node by JS, I noticed that you have to use .setAttribute. That's the only time I use it.

Btw: Neat website, add it to my feeds. Nice JS and layout.

tiffany said on May 30, 2007

I use setAttribute/getAttribute except where IE doesn't cooperate -- like with getting/setting class names.

Tino Zijdel said on May 30, 2007

I agree with PPK here, since some browsers (well, IE mainly) have poor/incorrect support for get/setAttribute I still mostly use element.attribute. This shouldn't be considered 'a rule' though, it's just practicing to the reality...

liorean said on May 31, 2007

The element.attribute syntax is more in line with JavaScript and also has better support, so that's my preferred way in HTML. In XHTML or XML I of course use the namespaced functions though.

By the way, having document.createAttribute as well as document.createAttributeNS is just about as foreign an interface as you can get from JavaScript - the idea that we'd have two different functions when there is no clash in the semantics for when the functionality is called with one or two arguments respectively is just not very JavaScript -like.

Scott said on June 01, 2007

These two methods are not equivalent.

For example, URI values such as a.href, img.src or form.method return absolute paths, while their DOM equivalents are strings that may represent relative or empty values. Also consider input.checked == true whereas input.getAttribute("checked") == "checked".

The right answer is that you should use different techniques based on the circumstances. The getter/setter properties a.href and img.src were around long before the DOM Level 1 spec, so these are sound to use for backwards compatibility. However, it is up to the browser vendor to implement these getters/setters for arbitrary DOM attributes, so you may find that obscure ones like th.getAttribute("scope") != th.scope in some browsers (hint: Safari 1.2).

Guilherme said on August 08, 2007

Well I just HATE the get/setAttribute. It is bigger and uglyer. And it is so limitating, one has to use strings. Actually I see this as a big mistake they've putted the get/setAttribute as the 'new default right way'. Why is it? Why should I call a function and pass string parameters to it, when I can just point directly to the property I want and change it?
I mean, the whole object oriented programming is about
You just go deeper in the object using dots, it is perfect!
If you think about it, the get/setAttribute looks like it is the actual older way, and that the .property is the new simpler improved way.
I dont really get what is the point of this setAttribute thing...

MoiDave said on March 07, 2011

Hey everybody! Cool forum! Ia€?ve found so much helpful advice here.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.