Fixing the mind first

What most hate, perhaps without even knowing, is not CSS per se, but non-systematic styling. It leads to all the grief developers and designers frequently experience. Non-systematic styling means, in short, thoughtlessly adding directives until the thing looks as intended.

Much of what’s suggested on this booklet hinges on the mantra “Always Be Refactoring” being practiced constantly, which is the only real solution to the aforementioned problem: seize every opportunity to reevaluate whether the code implements the best solution. This is the biggest benefit of *soft*ware.

A crop of strategies exists for addressing almost every styling problem under the sun. The problem then becomes understanding these strategies well (and some are very complex), which, best case scenario, will make you good at said strategy, while keeping you oblivious to the exact problems you’re dealing with. For no other part of the front-end stack this is truer than CSS. And for no other part of the stack, raw understanding will do more for you than any methodology ever will.

Understanding takes a little extra work initially, and next to nothing in the medium and long term, since it then expands by itself, exponentially. Applying a methodology without giving the problem any consideration invariably results in a constant game of exceptions due to what you remember versus what you forget to apply.

Directives-based programming, or configuring if you will, means every single “command” does a lot, which is unlike most programming languages. So things can get out of hand a lot more quickly. Directives that have implications beyond just the element they’re applied to (e.g.: display block vs inline-block) need to be carefully thought of and well understood.

It’s possible to use just CSS for doing this, if you agree to simply follow these rules by ear and do your calculations outside of your build process. Obviously, that’d be laborious, but the fact remains.

You can also implement all the rules explained in here using any other preprocessor. The science isn’t bound to Sass in any way.

We will write a lot of stuff from scratch, for which there are alternatives out there. The reason for that is none of the problems we’re trying to solve are by any means hard. What makes them appear hard is the fact you may not have invested enough time in understanding and embracing these problems. But fear not, for this is a much shorter road than you’d think.

Tooling correctly will assist you in getting there faster. You should have autoprefixer, and a way to compile Sass at your disposal. The former will allow you to write code without worrying about vendor prefixes, but more importantly, it unifies discrepant syntaxes such as gradients and flexbox. That is, you will write directive in the most current, standard way and it’ll output, alongside the original one, code that ensures it works in browsers that haven’t yet adopted the standard syntax.

Browser coverage for this booklet is IE9+, and Android 4+ (your mileage will vary, wildly, because of its precarious browser situation). Much of it will just work in IE8 by dropping in polyfills such as selectivizr.

Every chapter will yield one or more modules (or SCSS files), which you’re welcome to download first thing so you can use them before you jump into any actual reading.