Ordering CSS Declarations (blog.jim-nielsen.com)

One aspect of this is that, if your codebase has a consistent ordering rule like “alphabetical”, then you can be confident that deviations from the rule are intentional. If your codebase is inconsistent, you can never be sure whether a particular ordering represents an important edge case or is just careless

I'm learning html/CSS/JavaScript and as a novice I started ordering my CSS by appearance in the html.

I mean yeah, that's how the rules work... that's the cascading part, the fact that it's ordered in a cascading manner is right in the name of the language.

Alphabetical ordering sounds hilarious

If you can't automate it, don't bother. Fussing with enforced ordering costs me more than it gives in return. And I prefer rough grouping of related declarations anyway.

I started using alphabetic ordering for CSS some time back, and have found it much easier and more reliable than trying to keep CSS organized by importance / relevance / semantic content.

One correction to the article I want to make is that shorthand/longhand properties are more naturally alphabetized by placing the shorthand property first (rather than the opposite, as suggested by the author), so overriding them shouldn't ever be a problem.

I've seen places order only box model properties (first height/width, then padding, then border, etc, then everything else), order by responsibility (first fonts, then box model, etc)...

Here's what that gave us: crummy PR reviewers get a silly thing to complain about, developers get an extra thing to think about

Here's what that didn't give us: any reduction in bugs, any meaningful improvement in code legibility

I'm firmly in the camp of "order properties as needed."

CSS is ordered by definition, it's cascading so that's how it should read in order of speciticity

Completely agree with the sentiment here that property declaration order matters (and automation is not ideal). That said, none of the examples ring true for me personally. The author correctly debunks the vendor prefixes (tooling) and duplicate declarations (debugging) non-issues, however they appear to hold firm on the short / long hand natural sort order conclusion. At least in sublime text, hitting f5 to alpha-sort CSS results in the longhand properties correctly appearing after their shorthand versions. Needless to say, unless I'm being lazy (often), alpha sort is not just a pedantic feature in my stylesheets but a practical one too.

I order my declarations and have for years. Like many personalized code styles, it's much easier to maintain on a codebase you fly solo in.

My ordering is by my mental model of "impact" of the declaration. Generally: Display -> Position -> Box Model -> Text/Font -> Background -> Misc.

  /* Example from css file i have open */
  .officeBlock .email {
    display: inline-block;
    padding: 14px 10px 8px;
    background-color: #E0EFFE;
    border-radius: 50%;
    transition: 0.25s ease-out;
  }

Subjectively it's helpful for quickly understanding style blocks, particularly complex ones. Is the time investment a net positive? Possibly. I'd suggest it is worth trying on a project to see if it helps when you return to it months later, at least.

a smart guy i worked with early in my career taught us an order that i always liked "outside-in": display, position, flex, margin, padding, border, background color, text style, etc.. and i'm familiar enough with that approach to know how i like to handle the ones that aren't obvious, like opacity. but i don't think it's practical as a rule for a project with more than one or two people.

with more than 2 people and no automation or lint rule, it will inevitably not be enforced. and once you can't trust the codebase to be consistent, the usefulness of having a rule like that is gone.

alphabetical seems less intuitive to me but it at least has 100% objective answers to every question about what the order should be. no ambiguity and it's probably easier to automate or lint. if the choice is alphabetical, with automation, vs. wild-west, i'd take alphabetical.

I like using utility classes and single-concern components for pretty much everything, so selectors don’t have enough styles for it to matter.

My CSS property ordering preferences have changed a lot over the years, through some of those I see expressed in other comments:

- by category (display, position, etc)

- outside in

Then onto a variety of team preferences. Then I didn’t touch CSS for several years, as my “full stack” career became increasingly backend focused.

A previous team during that period had very strong (and sometimes idiosyncratic) code style preferences. I eventually cobbled as much of it as possible in an effort to remove those discussions from review so we could focus on more substantive discussion. But some of their preferences sank in and became my own. Of those less idiosyncratic, alphabetically ordering object properties (although I still prefer to make meaningful exceptions, eg for identifying keys or making the most important assignment most prominent) and aligning values really stuck. Both of which I had previously strongly disliked.

Anyway, when I left that job and returned to web dev, my instinct was: I want CSS properties to be alphabetized, but I’m sure it’ll never work. But after trying it, I’ve found it almost always does work!

The article gets at all of the cases I’ve encountered where it doesn’t, so I’ll defer to it. But I did want to add an anecdata as a previously skeptical convert.

Edit to add: and yes I agree with all of the comments saying this (or whatever ordering and any other code style preference) should be automated. Not just because I agree that improves the quality of review and diffs and reduces cognitive load, but also because meaningful exceptions are really hard to keep in mind under the best circumstances. Tools are not just there to do the chore, they’re also there to catch mistakes.

I like the concentric CSS style that this man defines: "Concentric CSS." 21 Mar. 2022, rhodesmill.org/brandon/2011/concentric-css.

Ordering from the outtermost properties to the innermost is both intuitive to write and pleasant to read. And if you're still new to CSS, it can help you to better understand and memorize the parts of the box model.

Honestly have no idea what the point of ordering CSS properties or imports in JS is, it’s just pointless busywork that has no meaningful impact, Ctrl+F and ripgrep exist. If it’s completely automated fine, but it is a massive pet peeve of mine to have these rules forced on dev teams, the benefit is so minuscule.