Custom Attributes: To use or not?

[jimbo_dk]

When writing unobtrusive JS, it's really convenient to have custom attributes inside of HTML elements. However, this would make the page invalid.

To get around this, I use an comma separated string inside of the REL and use JS to split it up. However, I'm wondering, what's the worst thing that could happen using custom attributes? It would make a lot of sense semantically to use them too.

[Raffles]

Gmail uses them extensively and I've seen them used elsewhere several times (can't remember where). I do agree that it can be tempting and seems neater and possibly less error-prone than to use space-separated lists in class or rel attributes. But then again it's easy enough to write bullet-proof hasClass, removeClass and addClass functions to make this a trivial job, removing the need for misusing the rel attribute. The class attribute seems to be vague enough to be used for practically anything, so it seems "OK" to dump loads of hooks into it.

Although custom attributes seem nice, they're not in the spec and so therefore I feel there's something inherently wrong with them. I'd be interested to hear what the knowledgeable folk have to say about this, and perhaps to gauge just how bad they are by the effusiveness of their responses.

[JimmyP]

This should be an interesting discussion.

To be honest though, I don't see why it's necessary to use custom attrs or class/rel to store info. Where would this method be applicable?

What's wrong with storing element info within corresponding arrays?

Have I got the wrong end of the stick here?

[felgall]

Nothing wrong with defining your own custom attributes for XHTML. The X is there to indicate that the language is eXtensible and so it is just a matter of creating your own doctype with whatever additional attributes you need. That's a very obtrusive way of doing your JavaScript though since the JavaScript to be completely unobtrusive needs to have nothing special added to the page to allow it to work at all since the ids and classes and parent/child/sibling relationships should already be more than adequate to be able to properly reference any part of the page without needing anything else.

You can't do it in HTML since the addition of any custom attributes there means you don't have HTML any more since HTML is NOT extensible.

[jimbo_dk]

Thanks for the replies guys. What I'm referring to is a situation where I would have a function that would be used like:

onclick="myfunc(arg1, arg2, arg3, arg4)"

That's a very obtrusive way of doing your JavaScript though since the JavaScript to be completely unobtrusive needs to have nothing special added to the page to allow it to work at all since the ids and classes and parent/child/sibling relationships should already be more than adequate to be able to properly reference any part of the page without needing anything else.

This seems to be the way to go ultimately. I wasn't looking at it like that. However, this means addition of a bit more code than normal.

[zcorpan]

Nothing wrong with defining your own custom attributes for XHTML.

Yes there is: your own custom attributes might clash with new features in some future level of XHTML and thus break in browsers that implement those features. (This has been a real problem for Opera when we implemented Web Forms 2.0 for instance.)

The X is there to indicate that the language is eXtensible

It's not open for anyone to extend XHTML. The "extensibility" in "XHTML" refers to using other namespaces -- not to ad-hoc add your own attributes to the XHTML language.

and so it is just a matter of creating your own doctype with whatever additional attributes you need.

Creating your own doctype does nothing but wasting your time.

(X)HTML5 has a solution to the problem that this thread is about: data-* attributes can be used without affecting the validity of the page and without clashing with future native features of (X)HTML. Just do:

<div data-icanhas="cheezburger"></div>

var kthx = div.getAttribute('data-icanhas');

[zcorpan]

(BTW, note that stuffing custom data in the rel attribute is subject to conflict with future rel values in (X)HTML, so even though a validator might not complain about it it could lead to the same problems as custom attributes. Using class is probably the safest choice if you're constrained to producing valid HTML4/XHTML1.)

[felgall]

The "extensibility" in "XHTML" refers to using other namespaces -- not to ad-hoc add your own attributes to the XHTML language.

I never said it didn't need for you to set up a separate namespace. Having multiple namespaces in XHTML is a part of what XHTML is all about which is why there are different DOM commands in JavaScript for XHTML t the ones for HTML so that the appropriate namespace can be identified.