the theory

The theory itself is pretty cool of course. Dump a data-pattern (or data-whatever) attribute in the html source (with the value of the attribute referencing the behavior of the pattern), have javascript pick up the attribute automatically and perform the needed javascript magic for the pattern to become fully functional. If you have a good set of javascript functions available, you could do quite a lot just be altering the html where needed.

why this doesn't fly

There's really no practical reason why this couldn't work of course, in fact we actually implemented it a couple of times like this and everything went pretty smooth. Take a list of articles, add data-pattern="carousel" and bang: there's your article carousel. Remove the data- attribute and it simply reverts to an ordinary article list. But there are some pretty bad drawbacks that have to be taken into account when you're opting to take this path.

The main problem is that we're attempting to tie and embed functionality directly into our html code by setting the data-pattern attribute. Remember all that fuzz about using presentational class names and how that conflicted with our html ideals? Well, this is exactly like that, only we're using functionality-driven data- attributes to do it this time around. You may not care about separating style and functionality from structure, but even then things could get messy real quick.

throw adaptive design into mix

When you're opting to implement an adaptive design, the real problem with using data- attributes for functionality kickstarting starts to materialize. What acts like a flyout on a mobile version of your site isn't necessarily a flyout on the desktop version of your site. What acts and is displayed as a carousel on mobile could just be a regular list on desktop. It's the perfect illustration that functionality isn't bound to a certain component, but could differ depending on the context and the instance of a component, which is why it doesn't belong into the html code.

html changes are costly

And finally there's the age-old argument that html changes are costly and should be avoided whenever possible. When the functionality of a component changes, this should not be reflected in the html, instead we should just be able to update the javascript file without touching the html code at all. That's not to say you can't add a few classes on the fly, but embedding it into the html is just plain wrong. This has been one of my prime concerns ever since I started focusing specifically on writing html code, so it's quite a mystery how this one could ever slip by me.

conclusion

Use your data- attributes as data containers for scripts, not as hooks to trigger certain script-fueled functionalities. We really don't need another tie-in, formally binding our html to our javascript code. Our html should be rich enough to identify the correct elements that need to be targeted with javascript anyway, so the use of data- attributes hardly reduces our work, it only makes our html code more confusing and less flexible. On top of that, the use and goal of the data- attribute can remain as pure and untainted.