3

Is it considered good practice to use DOM Element's getAttribute/setAttribute calls to associate additional information about contents of the element ?

For example I want to call setAttribute("MY_ATTRIBUTE_VALUE", "..."), where MY_ATTRIBUTE_VALUE isn't anything applicable to <div>.

Thanks !

RobG
  • 142,382
  • 31
  • 172
  • 209
ikaushan
  • 1,827
  • 3
  • 17
  • 20

3 Answers3

2

You should definitely go with data attributes. Here's an article on them. HTML5 Custom Data Attributes.

Bill Criswell
  • 32,161
  • 7
  • 75
  • 66
1

It is very good practise as long as you're setting custom data attributes, whose purpose is holding meta data about those elements. Data attributes take the form data-name where name can be any valid descriptor.

Traditionally people would add classes, and in some cases this is still appropriate (e.g. when a class describes the state of an attribute and also denotes a style class, for which class is primarily used).

davin
  • 44,863
  • 9
  • 78
  • 78
  • Presumably your answer is based on HTML5, which is not a standard and is not fully or even widely supported. Also, markup is about presentation, not data, so associating data with presentation objects is inconsistent with keeping presentation and data separate. – RobG Jun 23 '11 at 23:03
  • @RobG, what are you talking about? HTML5 **is** a standard. Whether or not the whole thing is widely supported/implemented is irrelevant: http://caniuse.com/ data attributes via getter/setter methods will work for every browser (including ie6 for example: http://stackoverflow.com/questions/2412947/do-html5-custom-data-attributes-work-in-ie-6/). Separation of concerns isn't a reason not to use data attributes, it just means to use them wisely. The presence of data will not change the presentation of the markup in different views in any way, so it doesn't hurt whatsoever. – davin Jun 24 '11 at 08:33
  • davin - HTML5 **is not** a standard. The latest W3C version is a [working draft](http://www.w3.org/TR/html5/). There are also various editor's and working drafts, but it has not reached recommendation status. Since there is no browser that supports all of it, support can only sensibly be described in terms of specific features. If you put data in presentation objects, then the program needs to know which objects to get the data from. If presentation of one or more data objects is combined, or one object distributed across two more UI objects, the data model has to know what is/goes where. – RobG Jun 24 '11 at 09:08
1

If you believe that markup is about presentation, then associating data with HTML elements is inconsistent with that philosophy. If you think that it doesn't matter, then use data- attributes introduced in HTML5. Note however that HTML5 is not a standard and is not yet that widely supported (if the term "supported" has any meaning in the context of a "living specification" that is constantly changing). However data- attributes likely won't upset most browsers but you must use get/setAttribute to access them reliably in a browser independant way.

It is considered good practice to keep data separate from presentation so that you can change the presentation to provide multiple views of the same data. If you bind data to the presentation, you reduce your ability to do that. It also means that changing the data model may well affect presentation unnecessarily.

Storing data in an object and relating it to the element (say by the element's id) will likely provie much faster access to the data (direct property access is much faster than function calls passing strings) and allow for a more flexible UI and data model.

RobG
  • 142,382
  • 31
  • 172
  • 209