The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Namespacing custom attributes in HTML

Background. I have read several threads around the topic of custom attributes. Seemed ejmalone was going for a similar implementation to that which I have in mind in another thread (it won't allow me to include a link yet... said I need more posts to "earn my stripes" to ensure I'm not spamming etc.)

Basic Idea. Namespace a custom attribute so as not to break a potential future spec'd attribute with the same name.

Example. <div myNamespace:myCustomAttr="myValue">...</div>

Thoughts. Seems robust, unless browsers start removing non-spec'd attributes, or the JS stopped seeing them so you couldn't set/get those attributes, or there was a spec'd namespace collision. Notable here - I'm not sure how I'm using "namespacing" here is materially different from naming the attribute something which is extremely unlikely to become standard (perhaps by prefixing with something special). Begs the question:

Questions.

I did not see a post in the threads I read indicating that something like my example above is likely to be a problem - now or ever - anyone have insight to the contrary?

Is JS just seeing the attribute name "myNamespace:myCustomAttr"?

Is it perhaps effectively the same as zcorpan's (if I recall correctly) note that the HTML 5 suggestion will definitely allow for a "data-" prefix to custom attributes for this purpose?

Additional Thoughts. Using the class attribute to store "additional information" is actually not always ideal - analogous to storing comma delimited values in a database field for example - you potentially have to post-process the string you get. Imagine you want to store a custom id for something - you could add a class such as myID_14, but that "14" is going to change with your use of this now "custom attribute" buried in the class attribute.

Hence, you have to parse out the 14 for it be useful. Albeit trivial, it's not so elegant.

In my opinion, a single call to getAttribute on a custom attribute is preferable.

I did not see a post in the threads I read indicating that something like my example above is likely to be a problem - now or ever - anyone have insight to the contrary?

Is JS just seeing the attribute name "myNamespace:myCustomAttr"?

Since HTML doesn't have the concept of namespaces, the result of using a colon in attribute names depends on whether you use text/html or XML. If the former, you get an attribute with no namespace, no prefix and the local name "mynamespace:mycustomattr". If the latter, you get an attribute with the namespace that the "myNamespace" prefix is bound to, and the local name "myCustomAttr".

So your JS has to use different checks for text/html and for XML.

Originally Posted by JSM

Is it perhaps effectively the same as zcorpan's (if I recall correctly) note that the HTML 5 suggestion will definitely allow for a "data-" prefix to custom attributes for this purpose?