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!

What is the WordPress dashboard for?

Right now, the WordPress dashboard is my least used and most visited page in the admin. I don’t know the history of why it was made and the decisions about it along the way. It seems like the why might be “because we needed a place for users to go when they logged in” and expanded from there.

Continue reading “What is the WordPress dashboard for?”

Fight with colors on my blog, please

George Stephanis and I created a nifty little WordPress plugin over the last couple days for funsies called Hugh.

Hugh allows to add a widget to your site that does one thing and one thing only. Hugh allows anyone on your site to change the color of your blog theme!

Continue reading “Fight with colors on my blog, please”