One thing I’ve noticed a lot lately with websites is that no matter how it looks, the style sheet is full of redundant, duplicate, or unnecessary styles. A lot of that, I imagine, comes from updates after a website goes live, where engineers that weren’t initially involved in its development are coming in blind. Another part of that might revolve around planning or distribution of tasks for a website’s construction.
Truth be told, there are probably dozens of reasons that the styles may not be as organized or clean as they could be. We can’t see the future and we can’t always be in constant communication with one another, but I’ve learned a thing or two over the last decade that I think might help keep things clean, organized, reusable, and readable.
Before We Start
A few setup notes here: I write my styles with SCSS. This is my preference. There are many other options out there—Less or Sass to name a couple—which will work in more or less the same way. I also typically use webpack or Gulp on older projects to compile and minify, auto-prefix, and concatenate my style sheets.
Organization and Breakdown
The organization is really up to the user. There is no one right way to organize your style sheets, but I’m going to share how I organize styles and why. The why is the more important aspect for the sake of reusability.
As far as I’m concerned, there are three parts of styling a website: utilities, global elements, and unique elements.
Utilities
Utilities are things like variables, functions, or Sass mixins to help you in building your website fast and efficiently, but is rarely utilized effectively. This is the most important area for improving our processes, but we’ll come back to that.
Global Elements
Global elements are parts of your website that are used universally across the site, or in my opinion, anything that may exist on two or more pages of your website in some capacity. These are things like your typography, your grid, input or button styles, card/graphic styles, icons, etc. The large majority of your website’s styles will fit into this category.
Unique Elements
Unique elements are exactly what they sound like: some part of your website that may only exist on one part of your website. This might be something as small as that one element that shows up only on the homepage or something bigger like all single post template—shared elements that only exist in one area of your website. They can, in this case, be reusable, but aren’t part of the global scope.
Here’s where we tend to get messed up. Things that exist on a single post template, to continue the example, will also exist in the Global Elements and will probably be rendered in part by Sass mixins or variables in use. In fact, most of that template will probably be informed by the global styles unless, for some reason, it’s completely different. We might start to dirty up our code when we don’t clearly acknowledge inherency and don’t take a larger advantage of our utilities.
Styles start to get a little dirty because there isn’t sufficient effort to educate incoming developers about how things are built or what elements are used, which is why it’s infinitely important to document your code.
Comment and Document
I don’t mean you need to write up a Github Wiki for every bit of code you write, but DocBlocks are important just as they are writing JavaScript or PHP, etc. At the very least we need to explain why things might go against the typically expected standards, overwrite global styles or if an !important is required, for example.
I take advantage of VSCode’s snippets to ensure that all of my SCSS start with a comment. At the least to determine what selector is used. We can’t always adhere to a BEM style structure, or inherently understandable class names, so it’s important to define what’s being styled if, at the least, there’s nothing else special about that block of code.
I might document minimally like:
// h2.
.title {
font-weight: bold;
} // .title.
If there’s something more involved in the block of styles, I might add a more specific note like this:
// Post Title. Overwrite parent theme.
.entry-title {
color: $color-red !important; // Force override parent theme.
font-weight: bold;
text-decoration: none;
} // .entry-title.
Of course I would do my best to style a selector in a parent theme before deciding an !important is required, but hopefully, you get my point.
I also find myself styling some object with multiple elements nested together; I separate those by an element comment to ensure each bit of styles are covered. This is a slimmed down example. Normally, I’d only implement this strategy on larger chunks of SCSS, but as an example.
//-----------------------------------------
// BLog River Post
//-----------------------------------------
//--------------------------------------------------------------
// Post River Card
//--------------------------------------------------------------
// article.
.post {
border: 1px solid $color-gallery;
background: $color-white;
padding: 1.5625rem;
//-----------------------------------------
// Post Title and Meta
//-----------------------------------------
// header.
.post-title {
font-weight: bold;
// span.
.date {
color: $color-alto;
font-weight: 400;
} // .date.
} // .post-title.
//-----------------------------------------
// Post Entry
//-----------------------------------------
// div.
.post-entry {
margin-bottom: 0;
// p. Inherits global styles.
p {
// Links in post entry.
a {
color: $color-sunshine; // Color differs from global link color.
} // a
} // p.
} // .post-entry.
//-----------------------------------------
// Post Footer
//-----------------------------------------
// footer.
.post-footer {
font-size: 0.875rem;
} // .post-footer.
} // .post.
This isn’t an immense amount of extra work in order to make sure that all of your selectors, class names and styles are documented and anything that differs from the global scope are noted. Anyone coming in after the fact should be able to gain a fairly decent understanding of what this is styling and of each element.
Intermission
At this point, we’ve organized our styles simply and documented our code fairly well. The level of organization and documentation will be dependent on your company’s code standards and general workflow and preference, but this is generally pretty simple and clean so far. The next missing element in creating a more efficiently styled website is the use of built-in and custom Sass functions and mixins.
Mixins
Mixins allow you to declare some SCSS that you want to reuse throughout the website. You can tie in Sass loops or functions to increase its extendability or functionality, but a general mixin might look like this:
@mixin card-style {
border: 1px solid $color-gallery;
background: $color-white;
padding: 1.5625rem;
}
And then it is used by simply calling @include card-style. This is a quick and easy way of adding easily-reusable styles to ensure that cards are consistent from page to page on your new website. I personally believe that you really shouldn’t vary from these styles for consistency’s sake—you shouldn’t have more than one similar-looking card styles on your site. But in the event that you want to extend this mixin, you could add some additional options, variables, or checks and take that simple mixin to something like this:
@mixin card-style($border: $color-alto, $background: $color-white, $padding: 1.5625rem) {
border: 1px solid $border;
background: $background;
padding: $padding;
}
This will output the same value as the card-style mixin above, but it also offers the ability to provide a custom border, background, and padding values if we like.
The goal here would be to create mixins for global elements or globally-utilized styles and document their usage. This ensures that styles for like elements are consistent, but it also cuts down on the amount of code actually needing to be written; and therefore, cuts down on the amount of time required for a project to some extent.
Extending Your Markup
Mixins are quick and easy, but there are many other ways that you can help quickly style your website by leveraging more complex mixins. Let’s take a look at a mixin that can be used to output presentational background and color classes that we can utilize directly in the markup.
I’d start by creating a new Sass map. Something like this:
$theme-colors: (
alto: $color-alto,
black: $color-black,
gallery: $color-gallery,
white: $color-white,
);
This gives me an iterable list of colors we can loop through in our mixin, which would look like this at a very simple level:
@mixin colors($colors: $theme-colors) {
@each $name, $color in $colors {
// Create background color classes.
.background-#{$name} {
background-color: $color;
}
// Create color classes.
.color-#{$name} {
color: $color;
}
}
}
This can be called once and, for each color, generate a background class and color class name for use anywhere in your markup.
<footer class="site-footer background-gallery"></footer>
This would render a selector with a background color that matches our variable.
I should note that my recommendation is that only colors that will be used should be added to this Sass map. Otherwise, you’re left with unused styles in your style sheet just taking up precious bytes of space.
Summation
Really the use of mixins or functions is endless. The goal here is to create as much reusable code as possible. The more you reuse, the more consistent your website will be when it’s built and when you inevitably add or update features in the future. Incoming devs can now leverages a well-documented pre-existing library of styles in which to pull from to help avoid adding new or redundant code into your repo and keeping things clean.