Organize your CSS properties however you dang like

Over the last several years, I have read several lengthy articles on how everyone should organize your CSS and why one method is better than another. In fact, I have even bought into several of these ideas in the past, but let’s take a look at what these systems are trying to solve and why they are largely unnecessary these days.

Generally, there seems to be a slowly-fought low-emotion war between alphabetization of CSS properties and “logical” groupings of properties. The methodologies tend to hinge on readability versus reducing the risk of duplicative code and are largely written to satisfy hypothetical problems . Let’s do a quick refresher on alphabetical versus “logical” groupings.

Alphabetical

For those of you unaware (and still here), alphabetical ordering is just as the name suggests. The properties are ordered alphabetically. Organizing alphabetically is done with the idea that it is predictable and it’s unlikely you’ll have duplicate properties.

Example:

.alpha {
  background: #fff;
  color: #333;
  font-size: 1rem;
  font-weight: 300;
  left: 0;
  line-height: 1.5;
  margin-bottom: 20px;
  padding: 0 20px;
  position: absolute;
  top: 55px;
  width: 70%;
}

“Logical” groupings

This is the category I have leaned toward in the past. It allows people to group things together in a way that is logical to them. Keep font stuff together. Keep positioning stuff together. Keep animation stuff together. You call it.

Example:

.logical {
  background: #fff;

  position: absolute;
    top: 55px;
    left: 0;

  margin-bottom: 20px;
  padding: 0 20px;
  width: 70%

  color: #333;
  font-size: 1rem;
  font-weight: 300;
  line-height: 1.5;
}

Neither are better for any reason

Yep. Spoiler. Neither matters all that much and you can use every method on the same project without the universe imploding. Time to debunk some stuff!

Ease of reading

I think we can all agree that alphabetical isn’t perfect. It’s starts to get pretty funky when you get into absolute or fixed positioning with various authors making various recommendations. It’s also only super quick to skim when you know what property you’re looking for. It’s also not super intuitive to gather all the font or box-model properties to see what’s going on.

Most “logical” groupings (even ones in different orders with different conventions than ones I regularly use) are straightforward to read. There aren’t too many problems. Usually people get positioning, box model, and typography properties grouped nicely even without training. Heck, at this point I would recommend not even bothering to stress too much where things go. Let people do their own thing. Worst case scenario, you have to skim through fifteen properties. More realistically, though, it’s usually only a couple.

But none of the above matters. 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. Yep. Digging through inspector where all of our sweet line breaks and comments get reduced to a single list, but once you find it there, you can hope to the file and modify your property. You don’t even have to look that hard!

I have one more minor point to make about readability: Most of the time, property lists are short. We’re talking two to six properties. Both methods often end up looking and operating just fine at that length.

Reducing the risk of duplicate properties

Use a linter. Seriously. We have tools that pay attention to this so we don’t have to. Alphabetical is still suspect to minor duplicative properties unless you eliminate shorthand properties like the following.

.duplicate-line-height {
  font: 15px/20px serif;
  line-height: 1.5;
}

In addition to a linter, implement a code review process on all code. Even just one extra set of eyes will catch these things. Not only that, but you’ll grow much quicker as a developer when you implement a good code review process.

The takeaway: Do what you want

I get it it. You’re passionate about things and like them to be predictable. So do I. It’s satisfying to write that way, but it turns out, it’s not essential to writing really beautiful CSS. Use multiple patterns in your project if you want. Encourage people to try different things with their property ordering. Some might work. Some might make you cringe a little, but relax. You no longer have to stress about keeping everyone’s properties in a single opinionated order. You can do yours exactly how you want and they can as well.

There’s an additional benefit to mixing it up. When properties aren’t in a predictable order, you actually have to spend a little time reading them. Don’t worry. We’re talking additional seconds, not minutes. Don’t panic. More often than not you’ll end up improving on code you never would have seen if you just skimmed down a list for your desired property.

What do you think?

Have I gone mad? Am I way off base? Is this going to be nightmare-fuel for you (I hope not)?

Safari, I want to love you, but I just can’t

I have been using Safari as my default browser for the last few months. I really wanted to see what Apple has been up to with their browser and wondered if I could use it effectively for designing and building websites.

The gist is that the browser is pretty dang nice for the most part. I love a bunch of the built-in features like their reader-mode (a must on hard-to-read sites). That said, it’s not the greatest for development or for having a bunch of tabs open.

Continue reading “Safari, I want to love you, but I just can’t”

On being a friggin cyber designer

I live in mild terror of a single question. It usually crops up when I meet someone for the first time. It’s not because the question is a difficult one for most people. In fact, it’s one many people enjoy answering.

What do you do?

Well, shit. I guess it’s time for me to attempt a meaningful answer to this. Here we go.

Continue reading “On being a friggin cyber designer”

Designing with OSS: Getting started

As few months ago, I decided to make an effort to see how much of my job I can do using only OSS (Open Source Software). I wanted to share my experience so far and welcome any tips/help you can share with me. This first post is about how I got started with a new computer/OS combo and not really much about design. The second (and third?) will be about using it to design.

Continue reading “Designing with OSS: Getting started”

How to unfuck permissions

When working with npm (Node Package Manager), I picked up the horrible habit of throwing a sudo in front of npm install or npm up. Usually, I only did it when I got an error. This is bad. It becomes a headache at some point. Here’s how to unfuck the permissions of the folder:

  1. Do this: sudo chown -R $USER ~/.npm
  2. And this: sudo chown -R $USER /usr/local/lib/node_modules
  3. And, if you get an error, maybe do the sudo chown -R $USER bit on the folder in question.

chown -R $USER simply changes the ownership to the user recursively to all the stuff in the folder.

Adios Vagrant, hello again MAMP (Pro)

I’ve been using VVV (Varying Vagrant Vagrants) for a bit over a year now with a few helper scripts for WordPress development primarily, but alas it’s time to end our relationship. The upkeep time isn’t worth it. It’s caused my computer to crash on a few occasions now. I’m not saying it’s bad by any means (it’s pretty dang awesome when it’s working), but it’s a bit more than I need with more moving pieces than I’d like.

Here’s a bit on my process moving from VVV to other stuff.
Continue reading “Adios Vagrant, hello again MAMP (Pro)”