DEV Community

Rails Designer
Rails Designer

Posted on • Originally published at railsdesigner.com

1

How to order attributes on HTML elements

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.

Image of Datadog

The Essential Toolkit for Front-end Developers

Take a user-centric approach to front-end monitoring that evolves alongside increasingly complex frameworks and single-page applications.

Get The Kit

Top comments (0)

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay