24

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?)

Asaprab
  • 288
  • 1
  • 3
  • 16
Tom Lehman
  • 85,973
  • 71
  • 200
  • 272
  • 4
    The lang attribute is a default html attribute used for normal, spoken language. Using this in the current context will conflict with it's default behaviour and is a perfect example WHY you should use the data-* prefix. – user007 Jun 28 '15 at 09:27
  • Data attributes have a major drawback : you cannot see easily the values set with JavaScript to an element, it will not appear in the DOM unless you get them from JavaScript. That's why I always use the shorter form even if it's a bit risky – Kiruahxh Nov 07 '19 at 20:28

2 Answers2

29

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. There is a convenient DOM API, HTMLElement.dataset, for accessing these attributes from scripts. It is now supported in most browsers.

  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.

Andrew Myers
  • 2,754
  • 5
  • 32
  • 40
Lachlan Hunt
  • 2,770
  • 1
  • 17
  • 7
  • 1
    I'm not holding my breath for (2), but (1) and (3) are good points – Tom Lehman Mar 16 '10 at 16:30
  • 1
    You're thinking of the days when browsers introduced new features only slowly, and only rarely. These days most browsers support the `dataset` element property to simplify access to `data-*` properties: http://caniuse.com/#feat=dataset – Jeff Walden Dec 17 '11 at 20:33
  • Is there a benefit to use dataset API? It's much easier for me to see the raw form of the attribute both visually and with IDE colorization, i.e. `timeslot.attributes['data-week-number']` than `timeslot.dataset.weekNumber`. Not to mention, easier to find/replace instances of it in the code. – Kerry Johnson Jul 08 '22 at 15:56
8

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
  • 20,883
  • 16
  • 73
  • 86
  • 2
    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) – Tom Lehman Mar 15 '10 at 22:39
  • 3
    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. –  Mar 15 '10 at 23:41