10

Possible Duplicate:
JavaScript setAttribute vs .attribute=
javascript dom, how to handle "special properties" as versus attributes?

Many times, in forums or places such as Usenet I have been told by some (when criticizing my code) that instead of saying, for example var link = a.href I should use var link = a.getAttribute('href'); instead. And use its complementary setAttribute() when wanting to assign.

They say it is the correct way to do it, that I am wrong, blah blah blah... I don’t normally pay any attention to those. And when I ask why nobody gives a real answer.

Now I am curious about in which cases it would be more suitable to use one or another.

In what cases would be more suitable to say var link = a.getAttribute('href'); instead of var link = a.href?
And in what cases shoulw I use setAttribute() to assign instead of assigning a value to a member directly by its identifier? i.e: `a.href = 'someURL';

Community
  • 1
  • 1
  • http://stackoverflow.com/questions/3919291/when-to-use-setattribute-vs-attribute-in-javascript/36581696#36581696 – Ben Apr 12 '16 at 19:03

2 Answers2

14

Whenever someone recommends a practice they should always justify the advice.

Reasons for not using getAttribute and setAttribute are than IE versions up to and including 8 at least have bugs in their implementation of those DOM methods. Also, browsers have differences in how they change DOM properties in response to the use of get/setAttribute.

However, browsers are remarkably consistent in regard to DOM properties, so it is much simpler to write cross browser code if you use DOM properties. The only caveat is that some browsers do not create DOM properties for non-standard HTML attributes, but they will all set them using properties.

An added bonus is that DOM property access is much faster than using a function call to get/setAttribute.

HTML5 is attempting to standardise some of these behaviours, but the problem with HTML5 is that it is not a W3C standard (and may never be) and that it is a "living specification" that attempts to not only document what browsers do (more or less) but also what its authors would like them to do without distinguishing between the two. So while it is helpful as a kind of "as built" specification plus wish list, it is quite useless as a standard.

Edit July 2017

The W3C has been publishing HTML 5 specifications for a while now (including numbered versions and lists of changes), and the WHATWG also publishes HTML and DOM standards with almost daily updates but without indicating what has changed. One or the other may give up eventually.

RobG
  • 142,382
  • 31
  • 172
  • 209
  • 1
    HTML5 is useless as a standard up to the point where browser manufacturers uniformly support it :-) That day is looking to be not far off. – Pointy Sep 02 '11 at 03:43
  • @Pointy - assuming the standard doesn't change too much in the mean time. And that everybody upgrades their browser. – nnnnnn Sep 02 '11 at 04:02
  • When dealing with forms, .getAttribute() is crucial if you need attributes of the from element, and avoid getting input fields instead. – enyo Dec 07 '13 at 17:51
  • @enyo—a far better strategy is to avoid standard form property names when naming form controls. For example, `getAttribute` will not help if a control is called `submit` or 'reset'. – RobG Dec 09 '13 at 04:10
1

I use the direct property access like obj.href when it's a standard attribute that all browsers support because I find the code a lot more readable and it works.

If it's a non-standard attribute or one I made up myself as a means of storing some data on the object, I use get/setAttribute().

I know of no reasons why one should always use get/setAttribute() and I've never had trouble in any browser using obj.id, obj.href, obj.className, obj.value, etc...

jfriend00
  • 683,504
  • 96
  • 985
  • 979