I have been heavily relying on CSS for a website that I am working on. Right now, all the CSS styles are being applied on a per tag basis, and so now I am trying to move it to more of an external styling to help with any future changes.
But now the problem is that I have noticed I am getting a "CSS Explosion". It is becoming difficult for me to decide how to best organize and abstract data within the CSS file.
I am using a large number of div
tags within the website, moving from a heavily table-based website. So I'm getting a lot of CSS selectors that look like this:
div.title {
background-color: blue;
color: white;
text-align: center;
}
div.footer {
/* Styles Here */
}
div.body {
/* Styles Here */
}
/* And many more */
It's not too bad yet, but as I am a beginner, I was wondering if recommendations could be made on how best to organize the various parts of a CSS file. I don't want to have a separate CSS attribute for every element on my website, and I always want the CSS file to be fairly intuitive and easy to read.
My ultimate goal is to make it easy to use the CSS files and demonstrate their power to increase the speed of web development. This way, other individuals that may work on this site in the future will also get into the practice of using good coding practices, rather than having to pick it up the way I did.
As said before me: Get into OOCSS. Sass/Less/Compass is tempting to use, but until vanilla CSS is used the right way Sass/Less/Compass will only get things worse.
First of all, read up about efficient css. try Google Page Speed and read what Souders have written about efficient css.
Then, enter OOCSS.
It will revolutionize every single bit about writing css. I am totally renewed and love it.
UPDATE: SMACSS is similar to OOCSS, but easier to adapt generally speaking.
I would recommend you to look at "Compass Style" CSS framework.
You should look at BEM.
Theory
BEM is an attempt to provide a set of instructions for organising and naming css selectors in an attempt to make things more re-usable and modular and to avoid clashes between selectors of the sort that often leads to spaghetti code and specificity headaches.
When it's used correctly it actually has some very positive effects.
BEM works well with SASS to bring an almost object oriented style to CSS. You can build modular files, that handle the display of a single UI element and contain variables, such as colours and 'methods' such as how internal elements are handled. While a hardcore OO programmer might balk at this idea, in fact, the applied concepts bring in a lot of the nicer parts of OO structures, such as modularity, loose coupling and tight cohesion and context free re-usability. You can even build in a way that looks like an encapsulated object by using Sass and the
&
operator.A more in depth article from Smashing Magazine can be found here; and one from Harry Roberts of CCS Wizardry (who anyone involved in css should have a read of) is here.
In Practice
I've used this, several times, along with having used SMACSS and OOCSS meaning I have something to compare them too. I've also worked in some big messes, often of my own, inexperienced creation.
When I use BEM in the real world I augment the technique with a couple of extra principles. I utilise utility classes - a good example is a wrapper class:
And I also rely somewhat on the cascade and specificity. Here the BEM module would be
.primary-box
and the.header
would be the context for a specific over-ride(I try my hardest to make everything as generic and context free as possible, meaning a good project almost everything is in the modules which are re-usable)
One final point I'd make here is that however small and un-complex your project may appear you should do this from the start, for two reasons:
Web Components
In 2015 we are starting to look at Web Components. I don't know a huge amount about these yet, but they look to bring all front end functionality together in self contained modules, effectively trying to apply the sorts of principles from BEM to the front end as a whole and componentise dispersed but wholly coupled elements such as DOM fragments, Js (MVC) and CSS that all build the same UI widget.
By doing this theyb will address some of the original issues that exist with css which we've tried to solve with things like BEM, while along the way making some of the other front end architecture more sane.
There's some further reading here and also a framework Polymer here which is well worth a look
Finally
I also think this is an excellent, modern best practice css guide - designed specifically for stopping large css projects from getting messy. I try to follow most of these.
The best way I've seen to counter
CSS
bloat is using Object Oriented CSS principles.There's even an OOCSS framework out there that's pretty good.
Some of the ideologies go against a lot of what's been said here in the top answers but once you know how to architect
CSS
in an object oriented fashion you'll see it actually work at keeping code lean & mean.The key thing here is to identify 'Objects' or building block patterns in your site and architect with them.
Facebook hired the creator of OOCSS, Nicole Sullivan to get a lot of savings in their front end code (HTML / CSS). Yes you can actually get savings not only in your CSS, but in your HTML too, which by the sound of it, is very possible for you as you mention converting a
table
based layout into a lot ofdiv
'sAnother great approach is similar in some aspects to OOCSS, is to plan and write your CSS to be scalable and modular from the start. Jonathan Snook has done a brilliant write up and book/ebook about SMACSS - Scalable and Modular Architecture for CSS
Let me hook you up with some links:
5 mistakes of massive CSS - (Video)
5 mistakes of massive CSS - (Slides)
CSS Bloat - (Slides)
I find the difficult thing is translating the required design for a site into a series of rules. If the site’s design is clear and rules-based, then your class names and CSS structure can flow from that. But if people are, over time, randomly adding little bits to the site that don’t make much sense, there’s not a lot you can do about that in the CSS.
I tend to organise my CSS files roughly like this:
CSS reset, based on Eric Meyer’s. (Because otherwise I find that, for most elements, I’ve got at least one or two rules that are just resetting default browser styles — most of my lists don’t look like the default HTML style for lists, for example.)
Grid system CSS, if the site calls for it. (I base mine on 960.gs)
Styles for components that appear on every page (headers, footers, etc)
Styles for components that are used in various places across the site
Styles that are only relevant on individual pages
As you can see, most of that depends on the design for the site. If the design’s clear and organised, your CSS can be. If not, you’re screwed.
May I suggest Less CSS Dynamic framework
It is similar to SASS as mentioned earlier.
It helps maintain CSS per parent class.
E.g.
What this does: Applies width:100% to both #child1 and #child2.
Also, #child1 specific CSS belongs to #parent.
This would render to