Why “Build Shit in CSS?”

A few years back, I gave a short talk on CSS to a group of programmers at a Giant Tech Company. The audience: a small group of pretty smart (but junior) developers who built web apps every day.

The first section was a quick overview of how specificity works. 10 seconds into explaining how each type of selector trumped the rest, the room filled with a murmur of aha moments from dev who’d been struggling for months to hack their way around Bootstrap with no idea why their code didn’t work.

It makes sense how this happens. Computer Science programs don’t teach pool of domain knowledge behind implementing difficult UI’s. That’s not a bad thing — it’s just outside the scope of their goals.

But if you’re a junior developer, where do you go to acquire The Knowledge? It’s spread across blog posts, talks and books, but I can’t point to a single “start here” resource the way I can for Python or Javascript.

At the request of people (aka @rebeccaestes) who wanted to learn, I wrote Build Shit in CSS to cover weird but important topics like how to work with floats, the practical difference between display properties, and other pieces of an intellectual toolkit that you use to make UI (including “when in doubt, check MDN.”).

An aside

Programming land has a problem: our documentation tends to be really good as a reference, but terrible at explaining ideas to people who don’t understand them already.

To be fair, writing about a topic in a way that makes sense to a person who knows nothing about it is an art form.

What I didn’t cover, and will right now

To keep the scope under control, Build Shit had to be focused on specifics. What it doesn’t go into is how to create maintainable CSS. And I’ve heard developers and big, high power companies discuss their struggles with this.

However, this is a solved problem.

  1. Create minimal base styles that cover standard typography and raw elements. These should be unopinionated and never change, unless you’re changing your workhorse fonts and colors.
  2. Everything else should be a namespaced component.
.site-nav {}
.site-nav li {}
.site-nav a {}
.site-nav .subnav {}
.site-nav .social {}

You can safely edit this code and know it only affects one thing, which you can look at as you make changes, and be confident that your changes won’t have side effects elsewhere.

Here’s what happens when you don’t namespace your styles:

h2 {color: red; font-size: 15px; margin: 0;}
// Now you have to override this everywhere you don't want h2's to be red.
// In some other file
.blog-post h2 {color: black;}
// In another file
.contact-form h2 {} // I actually want this to be red

Now, if you decide h2’s shouldn’t be red anymore, you have no idea where that base style is being depended on, and can’t be sure your change is safe without checking the entire site.

This is especially useful when building responsive sites. Because then you can implement the component’s behavior at different breakpoints in the same spot, and all knowledge of this particular UI element lives in one place.

.site-nav {
@media (max-width: 640px){
// ...

Will all the CSS be perfect? No. But this way if you wander into a file to change or fix something, you can be sure that you’ll only affect the components that you’re looking at right now, and the changes won’t trickle into other tightly bound code.

(BEM is a style of naming classes that uses this strategy, just with longer class names.)

To Be Continued

I’m looking to expand Build Shit in CSS, so if there’s another exercise you think I should cover, open an issue on Github.

This post originally appeared on whatisjasongoldstein.com, where I write about tech and post concert photos.