Backwards CSS

I recently handed off a prototype to coworker. A short while later my coworker asked if I had a minute to answer some questions on said prototype. After answering one of the questions I was greeted with the response:

So you write it backwards.

—My Coworker

This response has had me thinking about:

1. how I write CSS
2. how I defend my decisions when writing CSS
3. what the phrase “mobile first” means to me.

The following is a brief overview of how a write CSS in the context of responsive web design and why it works for me.

Prioritize Based on What’s Shared # fragment anchor

One of the first thing’s I do is evaluate what styles and rules will be a constant at all screen sizes and devices. This guides my strategy for creating a base set of rules to work from. This base represents the core experience from a CSS standpoint. Sound familiar?

This does not imply that base styles should be served to a larger screen or a smaller screen but my next point does.

Large Screens are More Complex # fragment anchor

Small screens have less space. In terms of CSS, less space = less complex layout. This is where “mobile first” factors into my workflow. So if larger screens have more complex layouts they will undoubtedly require more CSS. This is why I group most of my layout changes inside media queries using

@media only screen and (min-width:some-width) {}

So along with setting shared styles I include less complex layouts (smaller screens) as part of my base set rules. This allows me to minimize the amount of rules I override as the screen size gets larger and I trigger changes in design with media queries.

Consider the following example —

I start by defining some base styling for the .block-level-element with rules I know that will always apply for all screen sizes and devices like font-family and color.

When the size of the screen reaches the point where .block-level-element starts to take up two much space I introduce a media query to change the layout to accommodate.

@media only screen and (min-width: 40em) {
  .block-level-element {
    float:left;
    margin:0 1%;
    width:47%;
  }
} 

The advantages to this approach are that:

1. I Write less code (if layout is introduced with the base experience it needs to be removed and that means more code needs to be written)
2. I Leverage how block level elements act normally (This relates to the first item. Block level elements will take up as much horizontal space as they need based on their parent. On smaller screens this frequently means the width of the viewport.)

Styles for Free # fragment anchor

The thing I like the most about this approach is that it encourages me to write better CSS. It forces me to look at what is required for a base experience and what the browser already gives me for styling elements. I end up with a CSS code base that works with the browser rather against it.