Rationalizing
functional CSS

Marcelo Somers | October 7, 2016

When I first heard about the concept of functional CSS, it seemed crazy to me. “Why would I ever use this?” I thought. “I’m awesome at this.”

If you haven’t heard of it, functional CSS (otherwise known as atomic CSS, utility classes, immutable CSS — I could go on forever) is the idea that instead of writing big, monolith components in my CSS, I write small, single property, immutable classes that can be assembled into a larger component in HTML.

Your CSS might look like:

Which then gets constructed into your HTML as:

Crazy, right?

I loved writing really clever, powerful CSS classes. I argued for it because of “ease of developer consumption.” My goal was that a developer could add a single class to an element and it would automagically do everything for them. Basically, the opposite of functional CSS.

Then I read Adam Morse’s epic essay, CSS and Scalability. Adam takes you through a very comprehensive, informative journey—I recommend setting aside 20 minutes to read through his thinking—but here’s how I’d summarize it:

Okay, Adam. I’m sold. You’re right. It’s fun starting a new project and writing all these beautifully architected CSS components, but the fact is, I won’t always be there, and in the monolith model, the team will never stop writing CSS.

Raise your hand if you’ve ever walked into a really well-architected CSS codebase. Me neither. Typically, it’s not because the codebase started badly. It’s because as writers of CSS, we are taught to fix problems by slinging more code.

Much like Adam, I’ve reached the point in my career where I’m not very interested in what I can do with CSS. I’m interested in what I can help groups of people do with CSS.

Basscss and Adam’s own Tachyons were great starting points for experimentation. I was convinced after testing it out, and excited to get a chance to put this new approach to use during a recent client project. Three months into a functional approach to CSS architecture, I’m addicted. The times I’ve used the old monolith approach, it’s become a tedious challenge in jumping between files constantly. I think I’m convinced, but I’m still trying to rationalize scalability issues as my functional codebases grow and evolve.

Here’s what I’ve learned.

Speed

My goodness, I can work fast! I’ve always said that I can’t “design in code” and have preferred to start any blank-slate design in a tool like Sketch. I joked that it felt like two different sides of my brain that just wouldn’t mesh.

Using functional CSS has made me realize that it was the context switching that killed my creativity. I’d have a great design idea, but then I’d have to toggle over to my CSS file and start building up a component from scratch — naming it, thinking through the box model implications, DOM structure, best architecture practices, etc. This was like my creativity hitting a wall at 100 mph.

Now I’m able to cruise through the DOM, writing HTML and quickly styling each element as I go. Using Basscss—plus a few custom CSS classes for my brand colors (less than 75 additional lines total)—I was able to build out a homepage for a project in an hour that’s withstood the test of time.

And that alone feels like enough for me to keep using this approach. It’s addicting, and I don’t know that I can ever go back.

"The best CSS is the least CSS possible"

— kerning man (@jongold) April 22, 2016

Jon Gold was right: From a design perspective, Functional CSS frees you from having to make code decisions while designing. The decisions have already been made; you’re simply mixing and matching to achieve your desired styles in the same way that you’d use shapes, colors, and spacing in Sketch.

Transferability

On most projects I work on these days, our design and development teams have settled on the idea of design providing an HTML/CSS prototype and the dev team porting that into the real environment.

The efficiency gains on these projects have been enormous. A code prototype gives our designers time to perfect the user interface without the headache of having to learn to work in advanced JS frameworks like React or Angular.

The issues we’ve found with this approach are small differences in the HTML required: things like requiring a component or directive to be wrapped in a tag can break your CSS cascade pretty quickly. In the past, this meant maintaining an app-specific set of overrides, which over time led to more and more bugs (and more poorly written CSS ).

With functional CSS, small tweaks like margin adjustments can be made with a single class change in your HTML. It allows you to fix bugs without writing any additional CSS. I can’t even tell you how amazing this feels.

Stop making (pointless) decisions

Basscss provides a standard set of spacing and sizing utilities. Eliminating choice is actually quite liberating. By only being given the options of 8px, 16px, or 24px, you just pick small, medium, or large and roll with it.

I used to think this would take away all my creativity, but it’s just made my life easier as a designer. I can focus on the right problems.

Before we get into the issues with functional CSS, I want to be clear—at this point, I have more questions than criticisms. I’m sure much smarter people than me have come up with solutions (or justifications) for these problems. I’d love to learn what’s working (or not working) for others. Drop me a line if you’d like to share feedback.

Losing the cascade

Shifting our style assembly code burden over to HTML means we lose all benefits of the cascade. It’s wonderful the first time you create a component, but updating styles in an existing system can be a complicated mess of find and replace and other keyboard shortcuts.

A simple way to update a few close styles in a single file is to use multiple cursors. In Sublime Text and Atom, selecting a string of text and hitting ⌘-D (on Mac) will select the next instance of that string.

But this presumes you created multiple identical “components” by putting the utility classes in the same order, especially when doing find and replace across multiple pages. Otherwise, there is no easy way to search across your entire application to find where similar components were implemented.

This might be my single biggest concern about implementing functional CSS in a large app. Just imagine a standard “box” component made up of 7–10 utility classes. If you wanted to change the font size inside all the boxes, you’d need to find every instance across your app and update each one manually.

That leaves a lot of room for error.

Reusability of components

With functional CSS, creating a “component” is simply mashing together a bunch of classes. Reusing the component would require you to happen to use the same classes again in a different place.

Once again: a lot of room for error.

The long-term solution might be implementing a Pattern Library to document components and provide simple copy-and-paste snippets. Even better, by documenting, you easily provide “options,” if necessary, by describing certain types of classes that could be mixed and matched to achieve variations of the component. For example, maybe a card could have different header colors that are easily swapped by using a bg-color class.

Combined with the prior issue of losing the cascade, long-term reusability and the ability to update are among the major challenges I’ve encountered when working with functional CSS.

If you're working with components, adding a named class for each component could be a possible fix. It would be descriptive in that you wouldn’t actually apply any CSS to the class, but it would enable you to find instances of a particular component throughout your codebase.

Utility classes are easier to implement, but long-term usability, reusability, and the ability to update for large teams should be considered early on.

Responsive

Your string of classes is going to get quite complex if your design changes too much throughout breakpoints. Early on, it’s nice to do something like class=”m2 md-m0" to get two units of margin up to the medium breakpoint and then 0 margin above that.

But there was one situation in my test project when my navigation was restyled as a slide-in menu on mobile, which rendered as a standard horizontal list on desktop sizes. It quickly got out of control:

This was just the start. Later, more classes came on to style colors. When your design varies substantially between breakpoints, it can be a challenge to implement the classes (and your class order becomes another problem —we’ll discuss that in a bit).

Combat this by establishing standards early on for how to handle responsive;  naming conventions, breakpoints, and standardizing on min or max width all help.

Managing state

A common situation I find myself in is hiding a component by default and then clicking on something to show it. I might write a monolith CSS class like this:

Where Javascript would toggle .is-open. to show my navigation, now, my JavaScript would toggle a utility class of .block or similar:

Not too complicated on a small component for the sake of demonstration. But even in this case, you’d have to ensure that .block overrides .hide or remove .hide altogether (and remember to toggle it back). In a more complicated component, say where the position and styles change as well, this is a lot to remember to toggle via JavaScript.

Not a deal breaker, but it’s definitely easier to formulate your component in the CSS and just toggle a single class to handle all the styling.

Any project with more than one developer is going to have to set some standards around how classes are ordered. Otherwise, you’re going to be hunting and pecking through your class list to find what’s being applied. I’m personally a fan of the concentric model. But on top of source order, your team should decide if all the breakpoints should be grouped together:

or if the properties themselves should be grouped together:

I haven’t quite found which I prefer, so I’d be curious to know how other teams are handling this.

Documentation

In my CSS, I’ll often document strange properties and why I put something in a particular spot. Case in point: I could document why an immutable class exists in my CSS, but it’d be a bit strange to put why I added it to a particular HTML element within my HTML markup.

Overall I’m very happy with the functional approach to CSS. It’s one of those things that once you see you can’t unsee, and each time the change-averse part of my brain tries to write a monolith CSS class, I find myself drifting and uninterested in architecting CSS.

I find myself wanting to be done writing CSS. I want to write some classes early on in a project, and get designing by assembling those Lego bricks. Having to make code decisions late in a project just feels out of place — like I’m wasting my time writing CSS rather than actually solving real usability problems.

I’d love to hear from you if you’ve adopted this approach. If you’re interested in learning more about functional CSS, I highly recommend following Adam Morse, Jon Gold, and Brent Jackson—these guys are really pushing functional CSS forward.

Marcelo Somers originally published this post on Medium.