Clean CSS - detailed edition

A useful habit I've acquired over the years is to sort the properties for a component after what I consider to be most important. When I read CSS, I am usually most interested in how a component interacts with – and positions itself within – the world around it, and then how it organizes its internals. The least pressing matters are stuff like borders, colors and text decoration.

Whenever I write CSS, then, I try and place position and display at the very top. An added point here is that all additional properties which are connected with specific values for these properties should also be placed close by. For example, if you are using display: flex or position: absolute, add all your extra needed properties right away and be done with it.

width, height, margin and even z-index can fight it out for the next places, before it's time for padding, background, text-align and maybe an overflow. Finishing up, add all your color, text-transform, border and whatever other properties you might need. We are now officially in the "miscellaneous" section.

I think a small example might be in order. The following code (which I jumbled together based on some real production code) can be improved upon:

How does this component look? How big is it? Where is it placed on the page compared to the normal float? In order to answer all these, quite important, questions, you need to read the entire styling for the component and remember to place the relevant pieces of information together in your head yourself.

Now let's have a look at the exact same code after I have sorted it the way I think it should be written:

This way, the code right away tells you some pretty important facts about the component. It's positioned at the bottom middle of its ancestor. It is 80 by 60 pixels big, and it's probably always visible if it is in the viewport because of the high z-index. If you need to know how the text inside the component is styled, it's inviting you to have a look at the bottom, where it is all conveniently placed. You are welcome.

We could of course also have added some line breaks to make these distinctions even clearer, but I don't think it's really necessary. This sorting is already a major improvement.

When it comes to using media queries to make a site responsive, I have a simple, but powerful rule:

If you follow this rule from the start, you very rarely have to resort to using media queries with max-width or create ranges of media queries. This way, the breakpoints get so much easier to reason about, and you can usually get a good feel for how the site will look on different devices just by browsing the code. Be sure to always to sort the code ascending by screen size to minimize confusion. Of course, you should also try and be really sparse with your media queries, and write as little specific code as possible per screen size in the cases you really need to use them.

Here's a quick example to show you how this might look in a real project. Notice I am using less here in order to have access to predefined constants to use for the actual media query widths. That's a convenient way to make sure you never exceed five breakpoints on your site (which you probably shouldn't).

Good question! In my opinion, it is also then best to avoid anything else than min-width in your media queries. The trick here is to recognize that you usually can play around with the keywords initial, inherit and unset to negate whatever styling you had to apply only for the smallest screen size. You may of course also set the property to the value you want yourself, but these keywords convey more meaning to the reader than if you hard code some value yourself.

Example time:

In the last article, I said that you shouldn't write JavaScript for something that can be appropriately handled by CSS. While this, in my humble opinion, is rock solid advice, it might also sometimes lead to some rather complicated selectors. I'll use an example from my own project: A few months ago, I was trying to adjust the width of a list element based on how many elements there were in the list. I knew that this could be done with a few carefully crafted selectors, and after some googling and adjustment, I landed on a few variations over these selectors:

I agree, this looks quite scary. However, I still contend that it is the right choice to use CSS in order to achieve this styling. So what to do?

When I write code, I always try to surprise the next developer as little as possible. Oftentimes, the next developer is me, so this would have been the right thing to do even if I weren't the extremely nice guy that I am. I don't know any way to simplify this selector any further, so I guess this is one of the real, legitimate use-cases for a comment. Have a look at the same code with a comment:

This completely explains and justifies the complicated selector, and truthfully, when I stumbled upon this code myself weeks after I'd written it, I read the comment, and was more than a little satisfied with my own cleanliness. It's nice to see that I can surprise myself in a good way once in a while as well.

If you are actually creating a design where text wraps around an image, you hereby have my permission to go ahead and add a carefully placed float. If, instead, you are trying to create a layout for your page, position something to the left or to the right, or next to another thing, please use something else. display: flex, display: grid or even good old inline-block usually does the job a whole lot better than float has ever done. float works really well for its intended use, but at some point, people started using it to create entire layouts, because it was easier to create columns with it than any other tool at the time. Now, the world has moved on, and we no longer need to resort to adding a clearfix everywhere, or wondering why our containers suddenly have collapsed. Because we rarely use float anymore, it is actually even more confusing to find one lying around now than it was a decade ago. Please do everyone (most of all yourself) a favor and skip it.

I hope you found some of these tips useful. If you disagree with anything, or just want to reach out, feel free to shoot me an e-mail, and we'll have a chat. CSS you around!