Between the braces

In a post called Side Effects in CSS that he wrote a while back, Philip Walton talks about different kinds of challenges in writing CSS:

There are two types of problems in CSS: cosmetic problems and architectural problems.

The cosmetic problems are solved by making something look the way you want it to. The architectural problems are trickier because they have more long-term effects—maintainability, modularity, encapsulation; all that tricky stuff. Philip goes on to say:

If I had to choose between hiring an amazing designer who could replicate even the most complicated visual challenges easily in code and someone who understood the nuances of predictable and maintainable CSS, I’d choose the latter in a heartbeat.

This resonates with something I noticed a while back while I was doing some code reviews. Most of the time when I’m analysing CSS and trying to figure out how “good” it is—and I know that’s very subjective—I’m concerned with what’s on the outside of the curly braces.

selector {
    property: value;
}

The stuff inside the curly braces—the properties and values—that’s where the cosmetic problems get solved. It’s also the stuff that you can look up; I certainly don’t try to store all possible CSS properties and values in my head. It’s also easy to evaluate: Does it make the thing look like you want it to look? Yes? Good. It works.

The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?

I find it fascinating that most of the innovation in CSS from the browser makers and standards bodies arrives in the form of new properties and values—flexbox, grid, shapes, viewport units, and so on. Meanwhile there’s a whole other world of problems to be solved outside the curly braces. There’s not much that the browser makers or standards bodies can do to help us there. I think that’s why most of the really interesting ideas and thoughts around CSS in recent years have focused on that challenge.

Have you published a response to this? :

Responses

1 Share

# Shared by Gipsi Tana on Sunday, November 27th, 2016 at 5:16pm

2 Likes

# Liked by Alexander Skogberg on Saturday, November 26th, 2016 at 6:49pm

# Liked by Gipsi Tana on Sunday, November 27th, 2016 at 5:42pm

Related posts

Progressive disclosure defaults

If you’re going to toggle the display of content with CSS, make sure the more complex selector does the hiding, not the showing.

Making the Patterns Day website

The joy of getting hands-on with HTML and CSS.

Supporting logical properties

Using the CSS trinity of feature queries, logical properties, and unset.

Let’s get logical

Let me hear your blocky talk.

Faulty logic

CSS logical properties here, they just aren’t evenly distributed yet.

Related links

My Modern CSS Reset | jakelazaroff.com

I like the approach here: logical properties and sensible default type and spacing.

Tagged with

I wasted a day on CSS selector performance to make a website load 2ms faster | Trys Mudford

Picture me holding Trys back and telling him, “Leave it alone, mate, it’s not worth it!”

Tagged with

Tagged with

Can you feel the rhythm‽ · 13 March 2024

Adam makes a very good point here: the term “vertical rhythm” is quite chauvanistic, unconciously defaulting to top-to-bottom writing modes; the term “logical rhythm” is more universal (and scalable).

Tagged with

CSS :has() Interactive Guide

This isn’t just a great explanation of :has(), it’s an excellent way of understanding selectors in general. I love how the examples are interactive!

Tagged with

Previously on this day

17 years ago I wrote BarCamp begins

The geeks do their thing.

17 years ago I wrote Return to London town

BarCamp London 3: this time it’s personal.

23 years ago I wrote Mac Expo

This is my first "remote" posting.