Group items tagged

Writing CSS is very much like having sex. Not everyone does it the same way and there is no particular “right” way to do it. I guess for me the similarities actually end there, seeing as writing CSS is something I do every day whereas having sex is…anyway I digress. The W3C have set the standards but beyond this, writing CSS is down to an individual’s preferences. Here are 5 little tips and ideas I’ve adopted in the last 6 months that you can use to make your CSS more streamlined, maintainable and easy to read. Written by Jon Disclaimer: The CSS example files are exactly that. They are not meant to be fully functional CSS documents. Class names in the CSS files are named merely so that you may visualise the document in your head (because there is no accompanying html), not because I condone the naming convention in them.

1) Make a table of contents At the top of your CSS document, write out a table of contents. For example, you could outline the different areas that your CSS document is styling (header, main, footer etc). Then, use a large, obvious section break to separate the areas. Not only does this make your CSS look neater, but when it comes to making quick adjustments to certain areas of your website at a later date, finding the corresponding area in your CSS will be much easier. View Example File 1

3) Isolate single properties that you are likely to reuse a lot If you find yourself using a single property a lot, isolate it to save yourself repeating it over and over again and also enabling you to change the display of all parts of the site that use it. View Example File 3

How should a CSS framework be built? There are several possible ways to go about building a framework, but the most common and arguably the most useful is to abstract your common CSS into individual stylesheets that each cover a particular part of the whole. For example, you may have a stylesheet that sets up the typography and another that handles the mass reset. The beauty of the approach is the ability to selectively include only the styles that you need. You may end up with six or seven different stylesheets in your framework, but if a particular project doesn’t need one or two of them, they don’t have to be included. The framework we created in our office has five stylesheets: reset.css—handles the mass reset. type.css—handles the typography. grid.css—handles the layout grid. widgets.css—handles widgets like tabs, drop-down menus, and “read more” buttons. base.css—includes all the other stylesheets, so that we only need to call base.css from our (X)HTML documents to use the entire framework.

A word of caution This method works quite well, but there is a valid concern to be raised: it adds to the number of HTTP connections needed to render each page. On large, high-traffic sites, adding five more HTTP connections to every page view may result in angry system administrators. Two possible solutions to this are: Include everything in a single file, rather than breaking it into modules. The problem here is that you lose the ability to include only certain parts of the framework, and you also make maintenance more difficult. Have a server-side process that dynamically flattens the individual files into a single response. I’ve not seen this done, but it could be very efficient if done well. Using my example framework above, this dynamic process could occur when base.css is requested, but not when type.css, grids.css, etc. are. This way, the individual components are still available, but the entire framework is available in a flattened version, as well.