Advertisement

“Outside In” — Ordering CSS Properties by Importance

by

This article is all about CSS code structure - specifically about a method I've been using for the last few years to bring some logic and consistency to the order in which I write my CSS. It’s a method I call “Outside In”.

Declaration Order?

I've heard of various approaches to writing CSS in the past. Some people don't use any particular order at all, others alphabetise declarations by property name, I've even heard of a handful of cases where some order them visually by the length of each property:value pair! 

A past poll on CSS-Tricks asked this question with a result that I found quite surprising: 39% of over 11,000 people have no specific plan when it comes to ordering CSS.

How do you order your CSS properties
How do you order your CSS properties? Total Voters: 11,093

Grouping by type might suggest height being next to width. Alphabetically would see declarations listed from background through to z-index, for example.

I use the method of grouping properties by type - although I even use a specific order for ordering by group!

With the exception of the “random method”, there is some degree of order in all of the other approaches. But that order doesn't necessarily map well to anything particularly useful regarding the styling of websites. 

If you were collecting data about the height of students in a classroom, ordering them by a length measurement makes sense. If you're categorising a collection of DVDs, alphabetical ordering might make sense.  But would CSS properties ordered in these ways have anything to do with their order of importance when those styles are painted by the browser? 

If ordering alphabetically, is an element's color more important than its width? Is an element's border-style more important than whether or not it's in the normal flow of the document? I'd say not.

Outside In

The method that I’ve come to love orders CSS properties by how much impact they have on the selected elements or other elements around them. The gist of the technique is to start with big-picture properties which impact stuff outside the element and work in towards the finer details. This is why I call it the “Outside In” method.

position and float declarations remove elements from their normal flow and have a huge impact on other elements around them. This is something important and I feel it should be made clear right at the top of a block of CSS. 

Controlling things like the cursor or overflow of an element are (usually) less important and therefore I tend to leave things like this towards the end. 

The order I use is as follows: 

  • Layout Properties (position, float, clear, display)
  • Box Model Properties (width, height, margin, padding)
  • Visual Properties (color, background, border, box-shadow)
  • Typography Properties (font-size, font-family, text-align, text-transform)
  • Misc Properties (cursor, overflow, z-index)

I know that border is a box-model property and z-index is related to position, but this order works for me. Even though I don't like alphabetical ordering, there's something that just feels right about putting z-index at the end...

Practical Example

Let's take the example of styling a button module. 

Let's start with a nice, meaningful class name like .button. I personally dislike contracted names like .btn and tend to favour long, descriptive class names where possible - it's just a personal preference, YMMV :)

/* <a href="#" class="button">Order now &rarr;</a> */
.button { }

We want to be able to manipulate vertical spacing around the button so will need to change the display from inline (the default for anchor links) to inline-block

To allow the button to grow in width depending on the text content, inline-block is a more flexible choice than float with a width set.

.button {
    display:inline-block;
}

Next, we'll need to add some box-model characteristics like margin and padding. Margin goes outside the box so, going “Outside In”, this should come first.

.button {
    display:inline-block;
    margin:1em 0;
    padding:1em 4em;
}

The next things to add are the colours. To separate out each group of property types, I like to leave a blank line - this makes each section stand out a lot more.

.button {
    display:inline-block;
    margin:1em 0;
    padding:0.5em 3em;

    color:#fff;
    background:#196e76;
}

Next we can add in the borders and shadows to provide some depth, followed by any typography properties, again separated by a blank line.

.button {
    display:inline-block;
    margin:1em 0;
    padding:1em 4em;

    color:#fff;
    background:#196e76;
    border:0.25em solid #196e76;
    box-shadow:inset 0.25em 0.25em 0.5em rgba(0,0,0,0.3), 
               0.5em 0.5em 0 #444;

    font-size:3em;
    font-family:Avenir, Helvetica, Arial, sans-serif;
    text-align:center;
    text-transform:uppercase;
    text-decoration:none;
}

Reading Code

One benefit of having a system like this is that it removes the need to think too much once it's been implemented. If I'm reading through my code and want to change something big-picture like an element's width or position, I know I'll be looking towards the top of a rule.  If I want to adjust something like text-transform or list-style, I'll be looking towards the bottom of the block.

Having the code structured like this is also really hand for others reading the CSS; if faced with code organised like this, it's very easy to see all the component parts that make up a button module. When writing code, it's important to make it as easy as possible to our fellow developers to read; this makes code easier to understand and maintain.

Preprocessors

I've used vanilla CSS to explain my methods here, but you can apply the “Outside In” approach just as effectively in your Sass, LESS and Stylus.

Conclusion

Coding can be a very personal thing. If you use a different method for organising your CSS, it would be great to hear about it! Leave a comment to continue the discussion.

Advertisement