Composable SCSS for the Functional Programmer
All artwork in this article is by Andrew B. Myers via ButDoesItFloat
—
The CSS world doesn’t get a lot of forward thinking.
The more engineer-ey types are usually more interested in the more turing-complete problems, whereas the designer-ey types often lack the experience & code-aplomb to write truly salient stylesheets.
At Sanctuary Computer, beautiful websites and apps are our bread and butter — making SCSS is our bread knife, and for the sake of agility, we’ve been searching for better ways to write maintainable SCSS.
That methodology must be:
- Flat & DRY
- Self Descriptive & Readable
- Configurable & Extensible
- Totally Flexible & Non-Limiting
Introducing Composable SCSS
—
In Composable SCSS, I like to visualize DOM nodes as streaming method calls.
More specifically:
HTML nodes (and their nested content) are the arguments; the CSS classes are individual, bite-sized functions that those arguments are piped into, resulting in a styled page. Tweaks to those classes will result in consistent, predictable changes in the visual output throughout the project.
CSS Classes should describe a single chunk of DOM behavior, rather than a complex component. They’re building blocks, not full structures.
In practice, this means Composable CSS results in really verbose HTML, and virtually no (specific) CSS.
A Real World Comparison:
—
Non-Composable, (Imperative) Semantic Styling:
The Composable CSS Alternative:
Where’s the SCSS? The underlying SCSS for this example is excluded because a) there’s no “semantics dependent” style used, and b) the classnames are self descriptive.
There’s more detail on building out these classes below.
In addition— here’s our in-house SCSS Styleguide:
At first glance, you’ll probably be *grossed out*. Verbose HTML isn’t the most harmonious code to look at.
However, let’s talk through the real-world advantages to this approach:
- Styling is independent of nested structures, meaning bloated, dead CSS is not a concern.
- Moving HTML to other parts of the project doesn’t mean you have to also move then refactor nested CSS. Moving HTML inherently means moving styling at the same time.
- HTML can be read and visualized (at multiple screen widths!) without zigzagging to-and-from a CSS file.
- Non-visual / backend coders can easily get great visual results from using the generic classes; and that styling will automatically update as the underlying classes are tweaked by frontenders.
- Most visual tweaks can be made quickly & directly from HTML, and when paired with LiveReload, this makes iteration and experimentation feel lightweight & frictionless.
Using SCSS Metaprogramming to generate your own Composable framework
—
There’s a few different strategies to quickly building up a Composable SCSS structure.
The key concerns are: Colors, Spacings, Grids, and Utilities.
Colors
For the sake of easy iterating, we break out colors into a SCSS Color Map, and loop through them to build out the necessary classes.
Spacings
Applying individual spacings to HTML elements is usually an arduous task.
No more! Simply include the snippet below in your SCSS build pipeline, and ensure $composable-unit is set.
Grids
Two important prerequisites of the Composable style are a) for any grid classes to be applied from HTML only, and b) for those classes to describe the grid at different breakpoints.
Thus far, Foundation & BaseCSS are the only two grids I’m aware of that work this way out of the box.
Both Frameworks are completely modular. We generally only use 4–6 Foundation SCSS Modules.
The Foundation grid also ships with an enormous amount of tweakability — something that’s totally inline with the Composable methodology:
Check out their _settings.scss for an idea of how truly flexible, non-limiting (and composable!) the Foundation Framework actually is.
Utilities
Utility classes are the ones that you kinda gotta apply here and there, and you can’t really get away without.
Foundation’s Text Align Classes:
BaseCSS’s Utility Layout Module:
Composable Aspect Ratio Module:
Dipping into (real) CSS
—
As cool as Composable CSS is, it’s not realistic to style the more involved parts of your application with inline micro-classes alone.
In the heavier parts of your codebase, it’s totally acceptable to “dip into CSS”. Slap an appropriate classname on your HTML Tree, and go for it! Just be sure to only use a semantic class when you’re styling it from a CSS file.
When used sparingly, the *presence* of a Semantic Class becomes a reliable telling point that communicates the actual presence of further styling hidden away in a CSS file.
Composable CSS should be your 80–90% solution to styling your project. For a better codebase, only “dip into CSS” as a last resort.
Thanks for Reading! If this article tickled your brain in the right way, you might also like An Agile Design Manifesto (for Ember.js).
I’m Hugh Francis on Medium, @_hhff on Twitter, and hhff on Github.
