I've tried that approach in the past. The reason I didn't promote it in the guide is because data attributes, in my experience, were more verbose than what we needed.

They were useful in cases where we needed to pass in additional information (e.g. data-qa="onClick"). But what we found was

- whether class or attribute, it was the same dependency on markup - selecting with [data-qa] was the same specificity as .qa - selecting with [data-qa] was just a little more verbose than the teams liked

But, this isn't me arguing against data attributes. I'm just stating that my experience went in the direction where we didn't see any huge benefit.

They're guidelines so, by all means, take what works, throw away the rest. This was a small guideline about how to name stuff, not build entire apps. So if that's the thing that doesn't work for your workstream, my feelings aren't hurt. Thanks for reading it, though, and sharing your thoughts.

I tend to do it that way because I tend to use Atomic css, and that has enough classnames already.