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:

  • 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.

Really appreciate any thoughts here!

Thanks all!