Blogging, Programming

CSS learnings from 2013

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?


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.


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.


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.


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.

Web Applications, Work

Guardian May 2013 Hackday

You can see the reportage in these two liveblogs: Day 1 and Day 2 (note the terrible naming conventions). The theme of the hackday was “growth”. For the most part I took the theme to mean growth hacking and I did a lot of work along those lines which is difficult to talk publicly about.

However my prior lunchtime hacks had revealed to me that one of the fundamental problems the Guardian has is the volume of content it produces. This is not inherently a bad thing but the key thing to understand is that there is vastly more content than can fit onto what are called “fronts” in the jargon. A front is something like the front page of the site or the Environment section. These fronts produce a lot of traffic to content and for regular readers they are the essential navigation tool for the Guardian’s content.

Therefore I was interested in how we consider the dimension of time and perhaps use it to our advantage to help present content. This aspect of my hackday work is more open because actually I need a lot of help to understand to and because I’ve made some effort to try and use the public Content API rather than our internal content.

I called this work the “Time Trilogy” because it consists of three web apps that each use time as a way of accessing Guardian content.

The three apps are Guardian Word Count which was the original and gives you a sense of the challenge of navigating the content. It is also pretty fun to watch during the day and see the words tick up. So the Word Count spawned TickTickTick and Guardian In Review. TickTickTick is really a daily content explorer and was the first tool I needed to start sorting and exploring the breakdown of what we produce. It is a tool at its heart for exploring the daily news cycle. In Review is slightly different, it takes the one hundred most popular pieces of content over the last seven days and renders it. Initially I wanted it to be a kind of automatically generated magazine but actually looking at what people liked meant that I couldn’t make my initial idea work. People really like videos of meteors and Russian car crashes. What it is now is a way to explore material in the medium term, for content that perhaps has left the news cycle but is still relevant.

Neither app is really finished and the way I work is that I am very reliant on having working software to understand what I am doing and what is wrong or right about my approach. TickTickTick is much closer to being a complete product than In Review and it is providing more insight into the nature of the content being produced. For example there is a massive cluster of material between three and five minutes long.

I am going to continue to work on the apps because they help give me feedback into my work and ultimately these prototypes and toys tend to graduate into working components or theory on the main site itself. I may blog a bit more about them individually as I move them closer to something that genuinely creates value. I’m curious about feedback but acting on it is limited by my aims for the apps and realistically the time I have available.

I also wanted to talk a little bit about how I was working this hack day because I decided to reject advice and work solo rather than part of a team (although I did a little bit of backseat driving on the online magazines product and I did come up with the idea that actually won the hackday (and will hopefully be implemented and awesome)). Working alone does mean that your creations are going to be quite rough but it helps cover a lot of ground, I ended up doing five hacks and working on a total of seven. Working with other people means communicating well whereas solo you just need to express what you want very quickly.

My preferred tool for these kinds of hacks is Python on App Engine, which is what I use for my lunchtime hacks and for which I have a standard application template. With each new application that I do I can start to move the common patterns into the template. To avoid having to faff around with testing I use a loosely functional paradigm that I’ve carried over from Wazoku. It generally works quite well but there are a lot of rules to doing it.

This time around I was doing a bit more frontend work than my day job requires because I was working solo. Again having the startup experience was useful because I was more rediscovering a skillset than learning it. Hacks also means selecting your platform and choosing for optimal output.

For that reason I only targeted Firefox and Chrome (Firefox was actually easier to develop for in terms of standards) and I made liberal use of client-side Less and Coffeescript. I was impressed with how good the error-handling was in both. An obscure bug can wipe out all the productivity gains of a higher-order language but both worked great for me.

On top of that I tried experimenting with the new departmental standard of SMACSS (or at least my cherry-picking of it) and I made a lot of use of both Knockout and Bacon.js.

When I say I made use of SMACSS essentially what I did was namespace my classes to produce simple selectors. This did get me out of a problem I had in In Review so while it is truly the ugliest CSS standard and I suspect in time we may come to hate its rejection of rich functionality I concede that it is effective. Expect to see some of it applied to the main website sometime soon.

Knockout isn’t that popular in the department due to performance issues at a particular level of complexity but for me it did a brilliant job of simply syncing the visual DOM to the data feeds. I was really happy with it, other people were using AngularJS for more dynamic applications but they also had a lot more code than I did and again working solo less is so much more.

Bacon.js was really interesting. A lot of my approach to Javascript is functional and event-based but so far the events have been manually worked via jQuery. Bacon made it easier to create event sources with generic handlers and I probably didn’t use 10% of its full features. I’m curious to see what the rest of the department thinks of it but for my hacks it has definitely earned a place.

It was nice to do something outside the run of normal work and one thing that is quite cool about the hackday is that you can use it to tackle a technology that is entirely new to you and not have to worry about whether you succeed or fail.

Next time (May I believe) I think I want to learn about browser plugins as this is a way of producing better functionality for the Guardian without the hassle of having to make it work for the general population of browsers. Some people’s hacks this time around could have been released to the app/plugin stores and we could have been getting valuable user feedback by now.