Another approach to using CSS

Working for a new company sometimes leads you ending up in various conflicts with existing programmers about code writing styles.

In my case the conflict was about the handling of our CSS files and how we should style our HTML markup.

My colleagues would style a typical page like this:

HTML

<!-- since we should not target elements by tag name we give it the class name .blogtitle instead -->
<h1 class="blogtitle">Cool title</h1>

GLOBAL SCSS

@mixin bigfont {font-size: 2em}

PAGE SCSS

/* probably you target the H1 specifically for only this page by using the parent .blog-index class */
.blog-index {
.......
.hero {
......
.blogtitle {@include bigfont}
}
}
// or
.blog-index {
......
.blogtitle {@include bigfont}
}
// or
.blogtitle {@include bigfont}

However, I suggested something different.

Suggested method

HTML

<h1 class="bigfont">Cool title</h1>

GLOBAL SCSS

.bigfont {font-size: 2em}

PAGE SCSS

:)

The problem with the current method is that each change/fix means that you have to create a new partial, think up a brand new name and add some more code to replicate functionality that already existed free of charge. You have to do this every time you want to reuse that mixin anywhere new. This is just increasing the amount of CSS you output for no real, tangible gains.

What I suggest is start reusing code that is already there and keep our CSS files DRY. In other words, we’d prefer to pollute the markup rather than the style sheet. We already use this method when creating eg. buttons.

<a role="button" class="btn btn-primary btn-sm navbar-btn btn-white" href="#">Login</a>

It can also be used for positioning elements:

<span class="text-right clearfix">read more</span>

Or styling them:

<span class="h4 text-info text-uppercase">read more</span>

Or manipulating our grid:

<div class="col-md-9 col-sm-12">…</div>

By the way, most popular CSS frameworks (Bootstrap, Foundation 6) are already using this concept extensively for years.

Should I even include CSS styles on our HTML page?

Google explicitly suggests to inline the part of CSS that style the above-the-fold content.

JS libraries like React suggest inlining the CSS into the DOM.

Of course we should not literally inline all our CSS styles; I am just trying to make the point that adding several classes in our markup is by no means a sin for semantics. Class names are intended to apply styles to elements. And this is precisely what I suggest.

CONCLUSION

Favor the multiple-class approach over using something like @extend: using multiple classes in your markup — as opposed to wrapping the classes up into a new one using a pre-processor.

  • Less bloat: we can build entire modules without adding a single line to the style sheets.
  • Less abstraction: there is no need to look for rules in a style sheet to figure out the styling of a template. It allows you to see quickly and explicitly which classes are acting on a piece of HTML.
  • Will always make page rendering faster: there is less inheritance and fewer CSS for the browser to execute.
  • Faster development: styling is driven by classes that are not related to content, so we can copy and paste existing modules to get started.
  • Very little maintenance on the CSS side: only a small set of rules are meant to change over time.
  • Allows for greater composition in that classes are not tightly bound to other styles in your CSS.

Many times the method suggested is not possible — a unique page design may require a unique styling specifically for the new page. Then custom CSS styles will be included in a new CSS partial specifically targeted to this page.

The goal is to have only 1 global CSS file, keeping custom CSS for each module/page/website at a minimum.

Even though this technique has been around for ages, I am still amazed to how few developers actually use it.

Thanks for reading and sharing :)

Further reading:
https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach/
http://cssguidelin.es/#object-orientation
http://alistapart.com/article/meaningful-css-style-like-you-mean-it
http://csswizardry.com/2014/03/naming-ui-components-in-oocss/