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)?

Design.blog

A fellow designer and coworker of mine at Automattic, John Maeda, has been curating articles on the fairly new design.blog since August last year. After WordCamp US, he invited Mel Choyce and me to write an article for it each.

He also asked me to design the cover. Designing the cover felt similar to coding for CSS Zen Garden, thought I had a tad more control over the HTML. Javascript, however, was a no go. I did some fancy Sass tricks to generate the absurd CSS for the animations. I hope you like it.

Here is my cover, which includes the links to Mel’s and my articles. You should also peruse and follow the various articles and covers produced on design.blog. They are quite delightful.

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”

blog. to .blog

I’m super excited to finally ditch my old blog.michaelarestad.com blog address for something a bit nicer. Thanks to my generous employer, I now am the super proud owner of michael.blog. I went through the process of setting up the domain on get.blog and I have to say, it was pretty dang slick. I moved all my content over via the importer (a little rough) and it’s now ready to go.

But what about old links?

Well, after a bit of googling, I found a plugin call Redirection by Automattic‘s own John Godley (I love it when my coworkers have already made the tool I need). It took some time, but after reading his instructions, I found it to be fairly simple to set up. Now it will redirect any links to my old site right on over to my new site. Pretty spiffy! Thanks John!

.blog everything

I also picked up a few other .blog addresses here and there including one for my pup (yeah I’m that guy). There are tons of sweet .blog domains available. Go get one!

Reclaiming my hard drive

In the middle of a Zoom call a couple weeks ago, I got a system notice that I was running out of space on my startup disk. It said I had 1.6 gigabytes free and the number was dropping rapidly.

Crap.

I did some quick measures to get through the call by deleting some unused virtual machines and unsynched an entire dropbox repo. Boom. Back up to 43.2 gigs. Nice. Good enough for the call.

After the call, I knew something had to be done. It’s not easy to figure out which folders and files are taking up space on a Mac out of the box, so I nabbed a paid app from the app store called DaisyDisk. I had seen it earlier and knew it was semi popular. Might as well take it for a spin.

Immediately after installing it and scanning my hard drive, it made it really easy to dig in and see where my space was going. 67 gigs were used in a folder called MobileSync. It’s the backups folder for devices. I hopped into iTunes and removed all my old backups. 67 GB gained.

I then opened up my applications and started removing ones I hadn’t used in some time as well as ones Apple had replaced like iPhoto and iMovie 9.9.

Removing Adobe apps was a little rougher using the Creative Cloud application. An app has to be updated to uninstall it. Yes, I could have just deleted the files, but I wanted to try the interface. I removed some of my unused Adobe products giving me a bit more space.

Now I’m back up to 128 GB of space. Not bad. I’ll have to do some more digging into Photos and Movies to see if I can kill their cloud caches or something. They add up to around 27 GB of space. Yeesh. I thought the cloud was for keeping stuff off my hard drive.