This article was originally published on Rails Designer

The order of attributes on HTML elements may seem like a thing you have never thought or cared about. But having a guideline helps keep your code consistent and have yet one other thing you don't have to think about.

Below is the order I am using. Share it with your team and use it as a guideline. I won't say this is the only right way, but it's the one I've been using successfully with numerous projects over the last decade (👨‍🦳).

I use the following grouping order:

1. identifier
2. functional
3. styles

In terms of the actual attributes per group:

Identifier

This is only the id-attribute. I always put it first. By definition it has to be unique, making it important enough. Using Turbo Streams you also want to keep easily track of the id-attributes.

Potentially the name attribute would also qualify.

Functional

This is a big group of attributes and the most fuzzy as they depend on the kind of HTML attribute. But within this group a distinction can be made between attributes within a form that all have different values and those who have not.

The variable attributes go before the static attributes.

Examples for variable attributes:

• value
• checked
• selected

And examples static attributes:

• type
• for
• required
• required
• readonly

Data attributes

As you likely use Stimulus, I want to highlight the order of my data-attributes as well.

1. controller
2. targets
3. outlets
4. values
5. actions

This is based on the amount of needing to look up a value for an attribute.

Styles

Anything that is for visuals of the element.

1. class
2. style

Style comes after class as it could “override” styling. It's not really overriding, as the actual rendering and application of styles depends on CSS specificity rules.

Automate

I personally don't use a tool like erb-lint, but I guess it could be added as a linter. Reach out if you know, would be interested to see if a PR makes sense (or is possible at all).

And that's it. As often with such articles, you may disagree or not think this is worth it at all. That's cool too. For me, like Rails, anything I don't have to think about, leaves me with mental space to think about the business logic of my apps.