views:

224

answers:

4

I've generally tried to stick with DOM-only attributes when writing Javascript. Now that I've switched from Prototype to jQuery, I can get some serious mileage out of adding my own attributes to various DOM elements, mostly in the realm of being able to set up a very readable coding convention for handling AJAX requests.

As a short example, this means I do things like

<div type="book" app_id="13">
    <a href="#" action="delete">delete</a>
</div>

And then I can set up code to find all <a> tags with an action attribute, find a parent with a type and app_id, and then do CRUD operations... all without me having to write additional code.

Are there any pitfalls (other than not being strictly XHTML complaint) that I should watch out for, and/or any good habits I should look to emulate? How about a standard way of setting up my own attribute namespace?

+6  A: 

According to this question, using XML namespaces in XHTML 1.0 is invalid. Adding your own attributes to the same namespace seems worse to me, as they're most certainly invalid, even as far as XML goes.

Were I doing this, I'd get my mileage out of class and rel attributes. For example:

<div class="book" id="book_13">
   <a href="http://example.com/url/to/delete/non/ajaxily" class="delete">delete</a>
</div>
Steve Pomeroy
Unfortunately, if you want to then use different classes to provide visual feedback (say, different backgrounds for a checked-out vs. not-checked-out book), you either need another wrapper element, or need to go with the custom-attribute route.
Don Werve
@Don - No, you don't. You can use multiple classes on any element, just separate them with spaces. "checked-out book due-tomorrow" for example is perfectly valid
Mark Hurd
@Mark - You are right but the way you say needs parsing which is not preferable. I would choose (and actually have chosen) the custom attribute path.
BYK
Exactly -- @BYK has hit the nail on the head. My goal is to minimize the amount of code I have to write and maintain, and an extra step to parse out the ID isn't part of that. It also breaks if I want to use the ID as a selector for some other reason.
Don Werve
A: 

I see nothing wrong with this approach. Actually I have seen many examples of this and I, myself, used this approach on many applications and have not faced with any obstacles except that validation issue. So I think you are free to go =)

BYK
You would definitely have to look out for accidentally using a name of an element that one or more browsers will act on. Most browsers accept certain attributes even if they're not necessarily valid (especially IE).
T Pops
A: 

I don't see anything wrong with adding invalid attributes unless someone is using some unknown browser that is super strict and fails on anything that isn't a standard. This could happen, I suppose... but it's doubtful...

One good alternative, though, would be to use the jQuery Metadata Plugin to store easily accessible key->value pairs from inside an attribute.

KyleFarris
+3  A: 

http://stackoverflow.com/questions/779832/can-i-store-custom-attributes-in-html-dom-like-a-database-record/780080#780080

The new HTML 5 data attributes might be what you are looking for.

http://ejohn.org/blog/html-5-data-attributes/

http://dev.w3.org/html5/spec/Overview.html#custom

I know it's not "XHTML" but at least it's part of some standard ;)

Chad Grant