How To Write Clean CSS (SASS)

Oh styling, probably a nightmare for most web developers. Sure we get things like

to clean things up and save the day for us — BUT it’s still not enough. I know over the years of my experience with web development, I have always dreaded writing stylesheets, simply because I would find myself overcomplicating and finding it hard to stay organized while working from the ground up with a new project.

Why CSS Frameworks Are A Nightmare

I’m sure I’m not the only one who dislikes using

CSS frameworks

in my projects. I would like to say I am a purist, however I still use things like SASS to save me from the disorganization of vanilla CSS.

Inline Styling

Inline styling is often very frowned upon, and not often used in modern practises. I believe that this is for two reasons:

Internationalization

Organization

Internationalization is a fairly large idea to wrap your head around; so I left the a link if you’d like to check it out.

Organization is key in styling a web application. Using something like bootstrap may speed your initial development time, however since we are relying on a third party to maintain our structure this can cause technical debt down the road.

When I say inline styling, I mostly mean using predefined classes in your markup — in large projects, managing this becomes a nightmare.

!important (Writing Custom Styles)

Have you ever working on a project with a CSS framework, and found yourself writing !important at the end of almost every line? Custom styles are a staple in most modern web applications. There are many design patterns we tend to follow when designing an application, which in that case — we can assume that using a CSS framework would speed things up — until, we want custom styling. Yes CSS stands for

Cascading Style Sheets

, which means that the workflow is similar to a water flow — we can simply just include our custom CSS after the CSS framework import, however even then we find ourselves writing verbose CSS, since we might even have to narrow down our CSS preciosity. More often than not, these CSS frameworks often use a lot of !important which completely bends the nature of CSS (cascading).

But CSS is hard

I’ve overheard so many conversations about how web developers, specifically that, front-end developers have no problem writing markup code, but when it comes to writing stylesheets they often find themselves at war with their styles.

Often times, I believe a good front-end developer can write any styles for their stylesheet, a lot faster than relying on a large CSS framework, where more than half of what is written is not being used.

This is a problem, CSS frameworks are used to unify designs; to keep things consistent, but are rather used to speed up development — which later on causes technical debt.

Why is CSS hard

I believe that most developers find writing stylesheets for their sites difficult because they:

Start out organized, then end up getting lazy and start writing CSS all over the place.

Start out disorganized, and continue with disorganization.

I believe, that with the help of SASS, the cascading nature of CSS really starts to make sense, and I believe that it becomes a lot easier to write styles, however SASS on it’s own wont do much for you — you have to continue to stay organized after setting up.

How To Use SASS To Write Organized Styles

So you’ve set up the wireframe in your markup. Assuming we have used some

reset

styling to reset the browsers default styling — we should have a blank page.

<main>
  <h1>Apples</h1>
  <p class="some-sub-title">The apple is the pomaceous fruit of the apple tree.</p>
  
  <article>
    <h2>Red Delicious</h2>
    <p>These bright red apples are the most common found in many
    supermarkets.</p>
    <p>... </p>
    <p>... </p>
  </article>

<article>
    <h2>Granny Smith</h2>
    <p>These juicy, green apples make a great filling for
    apple pies.</p>
    <p>... </p>
    <p>... </p>
  </article>
</main>

Which should look something like:

Writing A Skeleton In SASS

We want to write a skeleton for the above markup, that way we can use it for all of our

media queries

// oursass.scss
/*
main {
   h1 {

} p.some-sub-title { }

   article {
      h2 {

      }
      p {

}

   }
}
*/

Now, anytime we would like to style the above for any device, we can simply just keep this comment at the bottom of our stylesheet — this way we can easily copy and paste it into a new media query.

I will paste an example of a mobile first approach below:

// Less than 600px
main {
   h1 {
   }
   p.some-sub-title {
   }
   article {
      h2 {
      }
      p {
      }
    }
}

/* Larger than mobile (default point when grid becomes active) */ @media (min-width: 600px) {
   main {
      h1 {
      }
      p.some-sub-title {
      }
      article {
         h2 {
         }
         p {
         }
       }
   }
}

/* Larger than phablet */
@media (min-width: 900px) {
   main {
      h1 {
      }
      p.some-sub-title {
      }
      article {
         h2 {
         }
         p {
         }
       }
   }
}

/* Larger than tablet */
@media (min-width: 1200px) {
   main {
      h1 {
      }
      p.some-sub-title {
      }
      article {
         h2 {
         }
         p {
         }
       }
   }
}

// I will usually put my skeleton code here in a comment so I can always refer to an empty version of it in case I still somehow get confused about the structure of my styles.

You may look at this, and say that you wont be using changing a certain style of a certain screen size — so then what is the point of this?

Actually, Let’s Try Changing ~this~ Instead.

We’ve all heard

this one

before. We take an input (designs possibly from a designer) output it by writing the markup / styling, and then we get feedback. Often times, once we see the web app in action — once we can interact with it, our opinion changes, and we often want to change positioning, subtract / add padding, change colours, hover effects, etc.

Since the fact that writing a new component, or even a web app from scratch we go through many many revisions, we keep our skeletons around to minify the frustration we might have to face when trying to dig through our styles to see where to insert the desired new style. The reason why we include the skeleton in each breakpoint, is so that we don’t have to get confused about where the certain element we are trying to select is suppose to be, because in large applications, mapping where you should put a certain selector can be very frustrating.

Yea, I guess that’s pretty organized, but what about performance?

This is something I was very worried about when I first started writing my styles this way — however SASS automatically deletes empty selectors on compilation — in other words, we don’t have to worry about loading a bunch of empty selectors on production builds.

Wrapping Things Up

This sure isn’t rocket science, and I think that there are developers that choose to write their styles this way. However, when working on a project with a team, I often find that most developers are still leaning towards using CSS frameworks, when really — writing your own clean, organized vanilla solution is more future-proof, as we do not rely on anyone but ourselves.

Thanks for taking the time to read this article, I hope I opened up a new perspective for you on writing your styles.

Ciao!

Blog.