Cascading and cognitive overhead

When I started out learning to build websites, the web world was just moving from adding style declarations to every single element, to a generalised approach where one small-ish set of rules would apply to all of a website’s pages.

We transitioned from meaningless markup:

<font size="-1">A smaller heading1!</font>

to markup that described an element’s position in the page structure:

<h3>A smaller heading</h3>

This was the magic of CSS: because our markup had meaning, we could contain the style of all the elements in just a small set of rules that would sort of automatically work for new pages.

Styling things that don’t even exist yet

With CSS, you don’t just style that heading, you style the general thing ‘heading’, including the ones on pages that don’t exist yet, with lengths you hadn’t imagined yet.

Preparing for the unexpected is a large part of the art of authoring stylesheets. We don’t know what device a user is going to pick, we don’t need to know, but if it’s got a certain screen width, we can write rules to adapt the lay-out.

Cascade blaming

In modern approaches to CSS, some portray the cascade as a nuisance. In his (well-considered) article about REMs vs EMs (seriously, read it, it is good!), Zell Liew says:

What throws people off is that 1em can take on different values in different parts of the code

Harry Roberts responded to this on Twitter:

This, in a nutshell, is why I hate ems.

So about this ‘taking on different values on different parts of the code’: in any programming language that would be bad, a side effect, a bug, a problem. But for CSS, a declarative language, it is arguably the whole point of it. CSS is made to have a cascade: behaviour that inherits style declarations based on priorities.

I would argue the benefit of CSS is that it does unexpected things. Instead of having to style every heading individually (result: expected behaviour), it will style each heading for us, including the ones that don’t exist yet when we’re writing the style rule (result: unexpected behaviour).

This is something you need to keep in mind when writing stylesheets. Harry replied that the cascading behaviour of ems is ‘cognitive overhead’ that ‘isn’t worth it’. I concur it is cognitively challenging, and education is important (Harry personally does a lot of great CSS education), but so are many things in web development.

Complexity in CSS vs complexity in preprocessors

The benefit of cascading as a cognitively challenging thing: it is clearly defined in specifications.

Many features of the modern day CSS approach, such as custom mixins and functions, are defined by the (very smart) people behind projects like Bootstrap, Bourbon, Inuit et cetera. They, too, bring cognitive overhead, but have only their documentations to refer to for help.

Where the spec-defined complexities have always been explained in the spec, and books by people like Eric Meyer and Andy Clarke, many modern-day complexities in CSS are harder to learn. Arguably, they bring more cognitive overhead.