In one of our recent projects I decided to go with a CSS framework to cut down on development time and simplify work on complex visual grids. Our team already used Blueprint framework on another project and was happy with it, so my choice was obvious.
You may wonder what a CSS framework is. The concept is pretty simple — it is set of frequently used tools and elements that setup conventions across projects, reduce development time and reuse generic styles. The first time this idea was described was by Jeff Croft in his excellent article “Frameworks for Designers” in A List Apart magazine.
The project is almost completed and Blueprint was a good companion. After several weeks of work with this framework I’m ready to share some impressions.
Pros
Cut down development time. You can start working on a project with the browser’s defaults, pre-defined layout blocks, typography elements and generic styles. Also, you have a stylesheet for printing and set of IE hacks. This is a huge time saver!
Easy-to-use grid layout. Blueprint contains a strong set of rules to work with grids, so you can build a layout from simple bricks. I created a draft of a relatively complex layout in 15 minutes — amazing result.
Consistent naming across projects. Designers usually have their own preferable class names for generic styles, which may lead to problems in collaboration. Have you ever reviewed code just to figure out how the designer named some common style? And what about duplicate styles with different names? CSS frameworks help in setting up consistent naming across projects.
Cons
Mixing content with presentation in HTML markup. This is one of my main concerns. To create a grid-based layout you have to use predefined non-semantic class names. This makes your code a bit imperfect, but this is the price of speeding up development.
Never used functionality. For my needs Blueprint is too bloated. All these styles may be useful to quickly create a simple page or prototype from scratch, but in a real project I used only 20-30% of the functionality.
Rewriting default rules. A good practice in working with frameworks is to not modify their code, so you can always upgrade to latest version with bug-fixes and new features. This leads to rewriting most of the Blueprint rules inside your main CSS file. Together with never used functionality this creates additional bloat and longer page loading time.
Conclusion
Blueprint is truly an awesome CSS framework, but I will not use it in our next project. (However, I may use it for prototypes or documentation). For companies like Wildbit with high standards and experience in front-end development, it’s better to come up with internal coding guidelines and even our own framework.
2 Comments
I’ve been a little frustrated when I look into CSS frameworks, because the core of the idea is good — even important — but the implementations don’t seem to live up to the potential. Instead of controlling your layout with specific classes and ids you put in the page, the classes and ids should be fairly static and should be accompanied with the appropriate stylesheet. That is, a framework should be a set of stylesheets, or some kind of stylesheet builder, along with conventions about how you mark up your HTML.
That would probably also handle the problem of bloat, as you could choose the CSS features you want. An even better system would be one with markers in comments so these modules could be added or removed from the stylesheet after it has been edited. A toolchain that accepted CSS variables (maybe more constrained than the actual spec, but at least resolving intrastylesheet variables) would also help avoid expected edits directly to the stylesheet, and thus make upgrades easier.
Ian Bicking — October 29, 2008, 2:05 pm
I don’t really use Blueprint (yet) but I have done a bit of research on it and it appears some of the cons you mention are being addressed.
The compress utility included with Blueprint allows you to map semantic names like #header and #footer to map to .span-24 for example. You configure the mapping in a YAML file and run the compression script to process the source Blueprint files and output a customized version.
As far as unused rules go, that doesn’t sound like a particularly difficult problem to solve programatically. Last year I wrote a small utility that scanned the HTML on a page and figured out which CSS rules were not being used: http://gist.github.com/15470
Using the same basic approach a bot could crawl the site (or a list of files), keep track of which CSS rules are used, and then rewrite the CSS to include only those rules. You could have a list of rules to keep that may not necessarily appear on a crawled page (like styles for error messages). It could also filter out duplicate rules, so that the later rules overwrite the former ones.. that way you could alter the styles without actually changing the Blueprint source.
Dan Kubb — October 29, 2008, 2:33 pm
Write a comment