views:

143

answers:

3

So any custom data attribute that I use should start with "data-":

<li class="user" data-name="John Resig" data-city="Boston"
     data-lang="js" data-food="Bacon">
  <b>John says:</b> <span>Hello, how are you?</span>
</li>

Will anything bad happen if I just ignore this? I.e.:

<li class="user" name="John Resig" city="Boston"
     lang="js" food="Bacon">
  <b>John says:</b> <span>Hello, how are you?</span>
</li>

I guess one bad thing is that my custom attributes could conflict with HTML attributes with special meanings (e.g., name), but aside from this, is there a problem with just writing "example_text" instead of "data-example_text"? (It won't validate, but who cares?)

+1  A: 

According to John Resig, the whole purpose of the addition of these custom data attributes to the HTML5 sepcs is to allow to embed custom data in HTML while still being valid.

If you don't care about validation (and, as you said, your custom attributes are not colliding with existing HTML attributes like name, id, style, etc.), then I guess you don't have to use the data- prefix. But considering that this is not a huge cost for writing valid, compatible code, I don't see why you wouldn't do it.

Wookai
I guess my question is what value do I get from writing code that validates? (Given that having to type the meaningless "data-" prefix repeatedly isn't without cost)
Horace Loeb
For one thing, you get the fact that you can use a validator to find problems in your markup. This is a huge win when you're working on a page, because it's so easy to lose a closing div or something in a long page. If you periodically make sure your markup is valid, you're much more likely to be able to pinpoint inevitable errors soon after they appear.
pat
+5  A: 

There are several benefit for keeping custom attributes prefixed with data-*.

  1. It guarantees there will not be any clashes with extensions to HTML in future editions. This is a problem that has been encountered to some degree already with some of the new attributes introduced in HTML5, where existing sites were using attributes with the same name and expecting different and incompatible, custom behaviour. (e.g. the required attribute on input elements is known to have had some clashes on some popular websites in the past)

  2. Once browsers support the feature, they will provide a more convenient DOM API for accessing these attributes from scripts.

  3. They provide a clear indication of which attributes are custom attributes, and which ones are standardised attributes. This not only helps validators by allowing them to permit any attribute with data-* while still performing useful error checking for other attributes (e.g. to catch typos), it also helps make this aspect of the source code clearer to those reading it, including people who may work on a website after the original author.

Lachlan Hunt
I'm not holding my breath for (2), but (1) and (3) are good points
Horace Loeb
A: 

Oh, please XHTML. I missing you.

brainsqueezer