The Different Logical Ways to Group CSS Properties

Here’s a bit of CSS:

.module {
  background: rgba(198, 148, 72, 0.75);
  color: #222;
  clear: both;
  margin: 0 0 2rem 0;
  position: relative;
  overflow: hidden;
  display: flex;
  flex-direction: column;
  border: 2px solid black;
  border-radius: 4px;
  padding: 1rem;
  font-family: sans-serif;
  font-size: 0.9rem;
  line-height: 1.4;
  opacity: 1;
  transform: opacity 0.2s ease-in-out;
  transform-origin: right center;
}

That looks a lot like CSS I write. I’ll admit, I traditionally haven’t had much of an opinion about the ordering of CSS properties. I just add what I need. I think they end up largely “grouped” by related things, because that’s just how my brain spits them out.

Even though I don’t particularly mind this “random” (no real logic applied) arrangement, I can see arguments against it. If there was a duplicate declaration, it would be hard to spot, and might make for some mind-melding troubleshooting. It’s happened to me plenty of times, now that I’m thinking about it.

I also admit I do have some style guide preferences, like 2-spaces, spaces before the opening brace, one space after colons, and things like that. That’s another article.

Let’s take a look at some ways we could apply different logic to this ruleset.

Alphabetically

Let’s rearrange them all alphabetically:

.module {
  background: rgba(198, 148, 72, 0.75);
  border: 2px solid black;
  border-radius: 4px;
  clear: both;
  color: #222;
  display: flex;
  flex-direction: column;
  font-family: sans-serif;
  font-size: 0.9rem;
  line-height: 1.4;
  margin: 0 0 2rem 0;
  opacity: 1;
  overflow: hidden;
  padding: 1rem;
  position: relative;
  transform: opacity 0.2s ease-in-out;
  transform-origin: right center;
}

Now there is a little logic applied here. If you are specifically looking to see if this declaration has an opacity property name, you can scan through it to find where “o” is alphabetically in the list and, ideally, find it very quickly. You’ll have to trust that the alphabetical format is adhered to perfectly, but I can see the appeal.

Jerry Low is a big advocate:

“The alphabet has a universally understood order. Most of us can probably order things alphabetically without overloading our brains… The speed and non-ambiguous ordering is a strong enough argument for alphabetizing your CSS properties, but to me, the biggest advantage is in collaboration — the lack of learning curve.”

You also get some natural grouping happening here. Notice the font properties are together and the transform properties are together, just by virtue of their naming. In a happy accident, the flexbox stuff is next to each other as well, but slip a filter or fill property in there and they wouldn’t be. Some things you might expect to be next to each other, like margin and padding are not. Which leads us to…

Grouped by Type

As we saw “type” grouping happens naturally, a little, when you go alphabetical. But there are lots of exceptions, as so it might make sense to group properties by what they do instead of what they are called. I said “type” in quotes, because how we group properties into types is entirely up to us, it’s not a semantic or programatic concept.

With some blank lines to help separate types, maybe we end up like this:

.module {
  background: rgba(198, 148, 72, 0.75);
  color: #222;
  opacity: 1;

  border: 2px solid black;
  border-radius: 4px;

  font-family: sans-serif;
  font-size: 0.9rem;
  line-height: 1.4;
  
  position: relative;
  display: flex;
  flex-direction: column;
  clear: both;
  overflow: hidden;

  margin: 0 0 2rem 0;
  padding: 1rem;
  
  transform: opacity 0.2s ease-in-out;
  transform-origin: right center;
}

Then that begs the questions: How do you order the groups of types? What goes in what type? How do you order the properties within each type? Those questions don’t necessarily need answers, they’re just food for thought.

Michael Arestad, who doesn’t care much how you order properties, says:

“Usually people get positioning, box model, and typography properties grouped nicely even without training.”

But he does make clear that this “readability” stuff isn’t all that good of an argument:

“Ease of reading is a straw man argument by me. It’s easy to knock down because all that matters is the easy of finding a property. This is just as easy with either method and more often than not, in my experience, starts in the browser.”

By Line Length

Wanna get weird? More people that you might think do this:

.module {
  background: rgba(198, 148, 72, 0.75);
  transform: opacity 0.2s ease-in-out;
  transform-origin: right center;
  border: 2px solid black;
  font-family: sans-serif;
  flex-direction: column;
  margin: 0 0 2rem 0;
  position: relative;
  border-radius: 4px;
  font-size: 0.9rem;
  overflow: hidden;
  line-height: 1.4;
  display: flex;
  padding: 1rem;
  color: #222;
  clear: both;
  opacity: 1;
}

I don’t mean to be rude calling someone else’s coding style weird, but to me this seems to be an expression of being compulsive about something just for the sake of it. There are no advantages that I can see, other than it looks kinda neat. Plenty of disadvantages though, like changing a value may require you to reorder it.

CSS Comb

It’s worth mentioning CSS Comb, which is a project that organizes your CSS properties as it’s default out-of-box purpose.

sublimecss

It’s also extremely configurable. They have a 24-step configuration tool to get things just how you like them. I gotta say: this appeals to me. In fact I just created my own new config and plan to start using this. It seems especially nice in a team environment. This way you get the benefit of a logical ordering (if there is one!), plus a consistent and enforced code style, for nearly zero effort.

There is a PostCSS plugin as well. But remember it doesn’t matter how your processed CSS file ends up, we’re talking about processing our authored stylesheets here, so it probably makes the most sense as an in-IDE thing (which this plugin offers).

Others

Do you know of any more ways to organize your properties? How about “last added, by date”? In order of how much you like the property?! How important you deem the property to be??!!

Comments

  • Simon Layfield

    I tend to prefer this grouping:

    font/colour/background (passive attributes)
    shape/form/size (emphasis)
    positioning (layout)
    sugary stuff (e.g. animations)

    It wouldn’t bother me particularly if there was no logical order, and jumping in to other people’s code inevitably has a different (or lack of) convention. I do find, though, that this grouping happens naturally for me as part of the process of developing the look and purpose of elements, much like a checklist.

  • I developed my own method by accident (like I think most people do). I just did what made sense to me and stuck with it. Looks pretty much like this:

    positioning/display/layout
    backgrounds/colors
    fonts
    paddings/margins
    fancy/shmancy

    • Laura Montgomery

      I’m pretty much the same myself

    • Pretty much the same here 😀 except I put padding/margins after position 😛

  • Hans Dampf

    I prefer total chaos + css animated classes grouped at the end.

    • Victor Scopel

      I use almost the same, alphabetical + css animate grouped at the end.

  • gotofritz

    I find any ordering scheme other than alphabetical total madness. Why going through the trouble to invest time and effort in coming up with a scheme that “makes sense” (to you, someone else will have different ideas..) then have endless discussions about it with team members, then having to remember the order, then having to set up linting rules to enforce it – and all the time and energy to what end? What are the benefits?

    I just order them alphabetically. Easy, everyone understands it. Job done.

  • interesting article, I generally go for the arbitrary clumping by type, it just seems to make sense to me.

    I’ve seen some online autoprefixer’s which I use occasionally if I’m not in an environment with a build pipeline configured that try to align them all so they meet up in the middle on the colon which is a horrible method.

    couple of typos, “all that matters is the *easy* of finding a property”, “More people *that* you might think do this”

  • mcato

    Perhaps I’ll have to give some of these a try…

  • danjah

    Good topic! It’s underrated. I totally agree with the team work premise here, and while alphabetical is sort of universal and natural (not for everyone), I’ve always preferred grouping by type, by impact on surrounding elements.

    So for example, positioning. It affects surrounding elements to such a large extent, sometimes being lifted right out of flow, that it is the first thing about a block that you should keep in mind – when considering breaking changes.

    Moving to display type (and I can never decide if this comes before positioning because display: none; removes the element) and then box model from the outside in; margin, border, padding.

    Line-height and font-size/weight all also affect the element render location, so they come next.

    Then the progression continues on to “stylistic”, the stuff themers often want to change to make a dramatic visual impact without layout breaking changes (“ok folks, to make this a bit easier, just focus on the props at the bottom of the style block beneath the comment: // stylistic”).

    Mixins/includes/extends stomp all over alphabetization, maybe more things will in the future too. That’s not to say it’s not useful, but there’s already exceptions there so like any current solution there’s trade-offs to be made, right :)

    Anyway, I’ve been told I’m pedantic, and I’ve also been told that CSS I’ve written looks like something a thoughtful machine wrote, so read that as you like – just another, different kind of trade-off.

  • MJ

    Anarchy!

  • Brenden Seidel

    Thanks for sharing your thoughts on this! I’ve been struggling with this lately but haven’t taken the time to figure out a method. I thought about trying to sort the properties alphabetically, but, like you pointed out, didn’t want to separate related properties. I think I’ll give the PostCSS plugin a shot.

  • I generally group by type and try and stick to this order.

    display, position, sizing
    box presentation – background, borders, margin, padding
    content – font, color
    decoration – effects, animation, etc

    with Scss projects, I keep my @include and @extend properties at the top of the declaration and my @media queries at the bottom.

    • Jake Peattie

      Hey, that’s pretty much what I do. My thinking is that I order properties pretty much by how ‘fundamental’ they are to the element’s layout, and how much it’s going to effect the surrounding elements. So I end up with:

      Position (position, z-index, top, left etc.)
      Display (display, flex properties)
      Size (width, max-width etc.)
      Box model (Margin, padding, border)
      Fonts, type-related properties (text-align, text-decoration etc.)
      Colors (I put backgrounds and shadows in here)
      Animations

      Within each group I order in order of sub-properties (so font-style:, font-size: etc. get ordered they way they are in font:) then alphabetically.

      Makes sense in my head anyway!

    • Adam Griffin

      I do something similar to this. Sort of like grouping by order of importance in terms of how fundamental a property is.

  • nospam nospam

    My style = MESS = Mostly Eccentric Style Sheet

  • Lance Jonn Romanoff

    I lean toward alphabetical because it’s a universal system. Some other developer who works on my CSS won’t need to determine my groupings. Pet peeve: you’ve used “beg the question” wrong.

  • Sascha Müller

    I prefer the shortest property name on top, the longest property name at the bottom.
    (the sans-serif font do not work actually 😉
    .module {
    color: #222;
    clear: both;
    margin: 0 0 2rem 0;
    border: 2px solid black;
    opacity: 1;
    padding: 1rem;
    display: flex;
    position: relative;
    overflow: hidden;
    font-size: 0.9rem;
    transform: opacity 0.2s ease-in-out;
    background: rgba(198, 148, 72, 0.75);
    line-height: 1.4;
    font-family: sans-serif;
    border-radius: 4px;
    flex-direction: column;
    transform-origin: right center;
    }

    position is on top, so I know this element is not normal.

  • Arnaud Delafosse

    I tend to use a (not very strict) ‘outward’ order: bkgd/color, font/text, padding, border, margin, shadows/position/transition etc. That way I roughly know where to look if I’m searching for something or where to add new stuff. It’s also easier for someone else to read and edit.
    Funny how no-one seems to do that in the comments so far, I thought that was pretty bog standard.

  • spotnyk

    I usually do by box model going outside -> inside, then by type

  • http://codeguide.co/#css-declaration-order
    I’ve learned this long time ago, and still doing it in this way.
    1.Positioning
    2.Box model
    3.Typographic
    4.Visual

  • When I style structural HTML elements in CSS I use the CSS box model for inspiration. I start with the outermost properties like margins and borders and work my way in. I add special behaviors like animations last. I do presentational things like I do colors and fonts in a separate stylesheet for reasons that need not be explained.

  • Dmitry Zemnitskiy

    Isn’t it better to group css rules by property, not by selector, ie:

    .module1, .module2, .module3 {
    font-size: 1em;
    }

    .module1, .module3 {

    font-weight: bold;

    }

Related Articles