I'm writing several JavaScript plugins that are run automatically when the proper HTML markup is detected on the page. For example, when a tabs class is detected, the tabs plugin is loaded dynamically and it automatically applies the tab functionality. Any customization options for the JavaScript plugin are set via HTML5 data attributes, very similar to what Twitter's Bootstrap Framework does.

The appeal to the above system is that, once you have it working, you don't have worry about manually instantiating plugins, you just write your HTML markup. This is especially nice if people who don't know JavaScript well (or at all) want to make use of your plugins, which is one of my goals.

This setup has been working very well, but for some plugins, I'm finding that I need a more robust set of options. My choices seem to be having an element with many data-attributes or allowing for a single data-options attribute with a JSON options object as a value. Having a lot of attributes seems clunky and repetitive, but going the JSON route makes it slightly more complicated for novices and I'd like to avoid full-blown JavaScript in the attributes if I can. I'm not entirely sure which way is best.

  1. Is there a third option that I'm not considering?
  2. Are there any recommended best practices for this particular use case?

3 Answers 3


I've been working with a similar pattern over the past several months. My personal opinion is that it is ok to mix these two conventions depending on the needs of the plugin. If you have a small number (i.e. < 5) of well defined parameters or if you want to select elements based on a particular attribute then data attributes for each parameter is ok. If you have a large number of parameters, or if the parameters are highly dynamic (i.e. request parameters to an ajax call) then json within a data attribute may be more beneficial.

In any case, IMO it is very important to clearly document what the parameters are and how they should be used.

  • 1
    +1 for "clearly document"; the rest of the answer is pretty good, too. Documentation is not optional for anything other than a toy, one-developer, no-one-else-will-ever-look-under-the-hood app. And even then its a good idea. Commented Sep 23, 2012 at 16:18

As you pointed out, both of your approaches have good points, and drawbacks. I am currently working with the later, which I personally find easier to use. However, the first approach seems to be easier to read for others, so.. Instead of looking for an other, better solution you could just use both your ideas. How about this?

<div data-foo="bar" data-bar="foo" data-other="example">


<div data-options="{foo: 'bar', bar: 'foo', other: 'example'}">

I have been using the second option, a JSON object, for a long time, but have never really been happy with it. At first I was constructing the JSON object manually. That proved to be troublesome as it is easy to screw up the syntax. so I wrote a helper to programmatically create data-options.

That worked well as far as creating valid JSON is concerned, but I have never really been happy with the single quotes around the JSON object as the rest of my HTML attributes are double quoted.

Back when I started using the JSON options method, one thing it had going for it was that it could be accessed via getAttribute which at the time was more universally supported than the dataset property.

Now that dataset is more widely supported, I plan on using the first option, that is many data attributes on an element except where there are a lot of attributes or they are dynamic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.