Group items tagged

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.