On class, id and data HTML element attributes for frontend developers

Background

I am a frontend developer (nicely abbreviated as FED at Springer Nature, and I love that acronym). I am very passionate about it and do not understand why not every person in the world is passionate about frontend development. I am also very emotional, which I think goes well with passion. Whenever I find something that doesn’t feel right or is even not understandable to me, I tend to catch fire.

I recently realised that throughout Springer Nature Digital (SND)s codebases, FEDs are making use of some HTML attributes - different attributes and for different purposes: I am talking about ids, classes and custom data attributes.

When I started frontend development - or rather website development, as more than 25 years ago, the terms “frontend” and “backend” development did not exist for me - ids were used for referencing HTML elements. That stuck to my mind since and I saw no reason to question that - until recently. I noted that we use data-component attributes in client side JS, data-test attributes for tests (which are also written in JS, but not client side), classes for styling, and that somtimes I see class, id and data attributes used for anything - tests, styling, referencing in JS…

This was a state that felt wrong, so I started dissecting things and - thanks to the great network of professionals we have in our hands at SND - felt free to ask a question on the Slack frontend channel about what attributes other FEDs use to reference HTML elements in JS. My belief in ids being the only right thing for this purpose quickly fell. I then promised to sort out my thoughts on this and share them with you.

id attributes

id attributes are the only way to reference HTML elements from within other HTML elements. They tell the browser which label is attached to which input element, they tell screen readers where to get supplementary information from related HTML elements, and they act as local anchors to jump directly to the content you are interested in.

That’s quite something, and there’s no alternative for these use cases.

class attributes

class attributes - which, if you ask me, should not be discussed - are for styling. Nothing more and nothing less. CSS can get complex enough with classes alone, and that again is quite something, so I see no need for an additional purpose of class attributes.

custom data attributes

Custom data attributes are meant for anything the creators of HTML could not anticipate at the time they wrote the specification. We can now use them in JS for testing, for transferring render-time data into JS data structures and also for referencing elements that JS wants to deal with.

What I have learned

From the point of view I had after delving into this relatively shallow matter, it didn’t feel right any more to use the id attribute in JS. This is what data attributes are for, so it makes sense to adapt to that intention.

If I am working all alone on a project that will never be seen by another FED, I can use whatever I want as long as it works - I can even use !important CSS rules to iron out previous CSS structural weaknesses that I brought into existence.

But from the moment where any other FED (including the future me) gets hold of my work, it helps their brains to find a pattern they are used to. And what would be more common than common sense?

So this is what it all boils down to - common sense in using HTML element attributes.

This is why at SND we are using id attributes for referencing elements from within other elements in HTML, class attributes for styling and custom data attributes for JS - where data-test attributes are meant for testing and data-component attributes for client side JS.

Whenever you modify an HTML element that has a data-test attribute, you should better inform your friendly QA engineers about the change, so they can decide if they need to adjust their tests¹, and whenever you modify an HTML element that has a data-component attribute, you should check the client side JS functions for any adjustments that might be necessary (and in the best case, either the tests would then fail or you should add appropriate tests).

What I should have learned

After editing this post, I realise that my real lesson should not have been the correct use of element attributes, but the fact that old knowledge should be questioned - otherwise it may age badly.

One remaining question

The question remains whether it makes more sense to use data-component="name" or data-component-name, and some code editors highlight one version nicer than the other, but if you ask me, I leave that up to the FED in charge. We all want to express our personality, at least where it doesn’t hinder the understanding of other (future) FEDs.