SitePoint Sponsor

User Tag List

Results 1 to 3 of 3
  1. #1
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    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.


    Really appreciate any thoughts here!

    Thanks all!

    JSM

  2. #2
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JSM View Post
    • 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.

    Quote Originally Posted by JSM View Post
    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?
    Yeah, except data-* is simpler (and also valid if you use HTML5).
    Simon Pieters

  3. #3
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you zcorpan!!!

    Really appreciate the detailed response around how the "namespace" would be interpreted and accessed.

    To your points, including the simplicity and html validity down the road, I'll go for the data-* solution.


    Thanks again!

    JSM


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •