Ordering CSS Declarations

https://blog.jim-nielsen.com/2022/ordering-css-delcarations/

by sysadm1n • 4 years ago

44 23 4 years ago

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

account-5• 4 years ago

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

oneeyedpigeon• 4 years ago

This is more about ordering individual declarations within a block rather than blocks themselves.

jamal-kumar• 4 years ago

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

somishere3• 4 years ago

Yet, if you take a closer look at the language you'll see that it doesn't just work but is also a practical method for debugging, consistency, and working with larger teams.

Where it would be hilarious is at a selector level. lol. [edit] (that is, unless you follow a bem-like methodology. non-lol.)

gherkinnn• 4 years ago

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.

hmcdona1• 4 years ago

You can automate this with stylelint if you really want to and let the linter handle it.

https://stylelint.io/

caseyross• 4 years ago

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.

somishere3• 4 years ago

Completely agree. Apologies I made a separate comment re. the short/longhand concern. I wonder if this is an IDE specific issue or is the author referring to manually ordering?

jamesfinlayson• 4 years ago

Agreed - alphabetical is the one ordering that everyone knows, whereas importance or concentricity or whatever require memorising or looking up.

Ordering the properties at all probably isn't hugely important but if some declaration has 15+ properties, I like that I can zero in on the one I'm looking for rather than scanning each property or having to Ctrl+F to find what I'm looking for.

lelandfe• 4 years ago

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."

ramesh31• 4 years ago

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

Exact same experience working on a team that had this as a standard. It's absolute nonsense. It can be enforced with CSS linting at this point... but why? Never in my decade of writing CSS have I ever ever wished that the declarations in a codebase were alphabetically sorted for any reason. If your class declarations are that large in the first place, you should be breaking things down better.

micromacrofoot• 4 years ago

yeah it’s pure pedantry, the worst thing to introduce to pr reviews

nathias• 4 years ago

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

somishere3• 4 years ago

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.

liquidise• 4 years ago

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.

spartanatreyu• 4 years ago

I'm very much the same, but I lump it into: Hacks, Layout, Decoration, Animation, Misc.

I order every property in each bucket by their importance.

- Hacks: reserved for very special cases that solve an issue. I keep this at the top so it's the first thing I see for a class (e.g. box-sizing, -webkit-touch-callout, pointer-events, outline for debugging, etc...)

- Layout this usually means display, position, box-model.

- Decoration: this usually means border, background, text

- Animation: this usually means transitions, non-layout transforms and animations

- Misc: Anything out of the ordinary. Related media queries (soon to be replaced by container queries), scss nested elements, etc...

rojobuffalo• 4 years ago

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.

WiseWeasel• 4 years ago

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

eyelidlessness• 4 years ago

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.

VoodooJuJu• 4 years ago

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.

danamit• 4 years ago

My ordering of CSS is similar to this, but opacity and z-index has to go last.

mjrbrennan• 4 years ago

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.

Ordering CSS Declarations

Related Stories