I don’t do masses of CSS in my work but this year was an interesting one because there was acres of CSS being created due to the general acceptance that we just need to get on with implementing the responsive web. Leaving the fixed-width grid also meant having to rethink the structure and architecture of CSS and modernise the legacy styling which if we’re all honest is actually created organically and piecemeal as requirements drift in.

CSS Architecture

I struggled and fought with SMACSS but I’m now over it and think that the result in practice has shown that it is the most sensible way to do things today.

BEM felt overly complex and fussy while covering pretty much the same ideas as SMACSS. OOCSS was off-putting due to its weird appropriation of object-orientated programming concepts.

I did like its idea of using multiple classes to allow for composition of styles. But using the idea of multiple inheritance as a metaphor for this seemed to be bizarre. Don’t these people know how painful inheritance is?

Isolation

One of the big things I took from SMACSS is that isolation is more valuable than re-use. Using a system that guarantees that your styling rules are not going to have side-effects is massively powerful.

When you then try to abstract components and share rules between them you lose some of that isolation and you begin to recouple components.

Seeing CSS as a conflict between isolation and duplication was a powerful metaphor for making decisions as to how to structure things.

Pre-compilers

I’m pretty sure that when we look back at 2013 the invention of Turing-complete CSS pre-compilers is not going to be a high-point. The CSS generation languages have been important as a way of pushing the CSS specification forward and of proving ideas in practice. I’ve certainly been grateful to be able to use Less in prototyping for example.

The agreement of the need for CSS variables and for being able to do calculations with those variables is a credit to the pre-compilers. The problem they create is the complexity of their abstraction. Turning a declarative language into something more programmatic is problematic for all the reasons that programming languages have problems. DRY is good but compilation errors in your CSS doesn’t feel like progress to me.

Just as with user agent extensions I think that pre-compilers are a great test bed for innovation but what they need to lead to is a better syntax for declaring intention rather than a new language.

Migration

Having new ideas for organising and structuring CSS is great but we also need to reflect our new ideas in our old work. Well, that’s easy right? Now we have new ideas we’ll just call all our existing assets legacy and re-write the whole thing. It’ll probably only take three months or more…

For the project I worked most on I applied a rule of thumb that seemed to serve pretty well. All the new CSS architectures organise themselves around a concept of components or modules. If your existing CSS is more or less built around the same concept you should be able to adapt whatever structure you choose and retroactively apply it to your existing code.

If your existing code though is designed more around concepts of pages or tag styling then you need to rebuild it piecemeal. Introduce the new component with its styling build on the new standard and then go back and

Hacks and shame

I was quite taken by the idea of having the file of shame. However in practice developers preferred to have commented sections of the files with hacks in. And before long we had people accidentally adding non-hack rules after the hack commment-line and we also have hacks liberally sprinkled all over the place.

I lost the battle but the result has convinced me that you want one place for the hackery and you want it right at the bottom of the cascade.

The incentive should be to one day delete the file of shame.

Simplicity

Clearly this year the only person who was talking any sense in CSS (apart from Jonathan Snook) was Harry Roberts as I also liked the presentation where he pointed out that design needs to be regularised in the name of sanity. If we have some components that have a margin of 1rem and and some with a margin of 1.1rem because it looks better we need to be taking into account the cognitive burden of having those additional rules.

Creating independent components encouraged me to allow every one to be a special snowflake. It was good to have a counter-balancing principle to make sure that principal of least surprise applied.

Harry also made the sensible suggestion (in 2012!) that padding and margins be defined in just one vertical and horizontal direction. Thing about flow from top to bottom and left to right also helped me to stop make special cases and look for a more general declaration of what I was trying to describe.