Category: CSS

Fronteers 2011 – The videos

All the presentations at Fronteers 2011 have been recorded, and the first presentation (The Future is Native by Aral Balkan) has now been uploaded to vimeo, the other talks will follow soon. View the presentation below:

Aral Balkan | The Future is Native | Fronteers 2011 from Fronteers on Vimeo.

All videos will appear on this page at a later time:
http://vimeo.com/channels/fronteers11#30659519

Fronteers 2011 Day 2 – more thoughts

The second day promised to match the quality and depth of the talks on the first day and it totally fulfilled that promise. Although it started off a bit rocky for me, because I arrived about 20 minutes late for the first presentation, I still managed to get the most important information out of it. So let’s go through the various talks.Read More

Fronteers conference 2011 Day 1 – my thoughts

The past two days, I’ve been at the Fronteers 2011 conference. Fronteers is the Dutch trade union for front end developers and this is the fifth year they’ve organized this conference. Last year was the first time I went to the conference, which was okay. This year’s conference, however, was very much worth the time and money spent.

Read More

The problem of massive CSS

In the past few years, I’ve worked on several big websites as part of a front end team. And all those sites have the same problem: a cancerous growth of CSS. The problem starts out small; a designer changes the look of a new component of the site in such a way that existing CSS classes can’t be used, so the developer adds some new classes. However, over the years this process turns a few hundred lines of CSS into a few thousand lines (or even more than a few). And at some point the developer might not even try to reuse CSS code, because it’s easier to add a few more classes than to find the proper classes in all those lines of CSS. And so the problem of massive CSS is born.

So what is the solution for this problem? In my opinion, the solution has multiple layers. Firstly, for a large site a very strictly adhered style guide and component guide is a requirement. It might not be as much fun for the designers, but it is a very good way to maintain cohesion in the designs across a site. Secondly, build the component with reusability in mind. Don’t make them location dependent (i.e. it should be possible to put a component in the main column and in the sidebar without adding new CSS). This is quite difficult, but not impossible. If there is no other way, make sure to document this in your CSS and HTML. However, the hardest part to solving the issue is getting people on board with any new solution. People don’t like change, and there are actually people that thrive in the chaos of massive CSS.

Technically speaking, I think the best solution is Nicole Sullivan‘s Object Oriented CSS approach. Although the link goes to Github, it’s not only a technical solution, it’s a mindset solution (just like OOP). You need to learn to “see” the “objects” in a page that can work with the OOCSS approach. OOCSS also isn’t a silver bullet, you can’t use it for every single part of your website. However, it can work for the interface elements of your site: the elements that keep popping up all over your site. Things like content boxes, a picture with some text or a form field and label. The clue of OOCSS is figuring out a singular way of building a component and then sticking with it. Of course you can extend a component so that it becomes a new component (just as you extend a class in OOP), but you shouldn’t have two components that look similar on the same level in your “OOCSS hierarchy”.