When one builds out many designs with HTML and CSS, one finds that there are a handful of the same of problems you solve each and every time. Among them: Resetting browser defaults to create a blank slate. Setting up layout and baseline grids for your design to adhere to. Creating sane defaults for type sizes, alignment, and spacing. And more. Wouldn’t it be handy to have this stuff taken care of ahead of time, so you can get to the really fun stuff designers love?
Before joining Blue Flavor, I worked for The World Company, a news media company headquartered in Lawrence, KS. While there, myself and designers Nathan Borror and Christian Metts devised a sort of framework for CSS. The idea was to abstract away repetitive tasks we found ourselves doing over and over again on each and every site we built, such that we could focus our time and creativity energy on the unique and interesting aspects of each site. Although I wrote an article about the idea, we never released our framework. However, it was borrowed by Olav Bjorkoy and incorporated into BlueprintCSS, a publicly available CSS framework which strives to accomplish the same goals. Since its release, Olav and other contributors have advanced and extended Blueprint, and we’ve been using it some recently here at Blue Flavor. I thought I’d take a bit of time to talk about how we use it, how it’s impacted our workflow, and what we like about it.
What does Blueprint do?
Blueprint’s core feature set is as follows:
1. It performs a mass reset of browser default styles.
2. It sets up sensible defaults for typography, including font families, header sizes, paragraph styles, list styles, a baseline grid, and more. It does all of this with relative sizes, so that it scales well in any browser.
3. It gives you a methodology to use for customizable layout grids. Any number of columns and widths you can dream up is easily achievable.
4. It provides a sensible default print stylesheet.
5. It does all of these things in ways that work elegantly in most browsers your visitors are likely to be using, including Internet Explorer 6 and 7.
It’s important to understand that all elements are override-able. Blueprint doesn’t set out to be a stand-alone stylesheet for your site. Rather, it’s a set of base styles you, the designer, can build on top of, override, or nix completely (by adding your own stylesheet(s) in addition to the ones Blueprint provides).
Think of it like this: building a design with CSS is like having a bucket full of melted plastic to work with. Building with Blueprint as your base is like having a set of Legos—but you still also have that melted plastic if you need it.
The grid
Blueprint’s crown jewel is its grid-building tools. By default, Blueprint’s grids.css file sets up a 950px wide grid of 24 columns, each 30 pixels wide with 10 pixel gutters. This grid is likely to be flexible enough for most of your needs.
However, the grid is fully customizable. If you need more or less columns or a wider or narrower total width, you’ll want to use the Blueprint Grid CSS Generator tool. It not only provides a replacement grids.css file, but it also creates a grid.png image file for use as a background image during development—very handy for making sure everything lines up properly. The grid generator is a key piece to the framework, even if it’s technically a third-party tool. Without it, Blueprint is limiting and controlling, forcing designers to use a single layout grid. With it, designers have endless freedom.
Incorporating BlueprintCSS into your workflow
If you intend to use Blueprint to build a design, it’s best to decide this before you start working in Photoshop (or your design tool of choice). You can retrofit a design with Blueprint HTML and CSS, but it’s much simpler to plan it from the beginning.
The designer will want to hit the afore-mentioned grid generator tool to come up with the exact number of columns, gutter size, and total width they’re going to use. They should save the exported grid.css. Then, they can set up a Photoshop document with guides replicating this column structure.
At Blue Flavor, the designer may or may not be the same person that ends up building the HTML and CSS templates. When the designer hands off their finished comps to the HTML/CSS template author, he/she should make sure to also include the associated grid.css and let the template author know about the guides in the comp.
Tips, tricks, and best practices
When using Blueprint, it’s really important to read all of the included CSS and fully understand what everything does and how it works before you dive in too deeply. If you don’t, you’re likely to miss really important elements, such as the .border, .colborder, .box, and .hide classes.
Also, don’t be fooled by the grid documentation’s suggestion to use div elements for all column units. You can apply the .column class to any element. For example, if you’re using the default grid and you want a bar across the top of the page that includes your logo on the left and your navigation on the right, you can add class=“column span-12” to an h1 and a ul, rather than making unnecessary divs.
Use multiple .container divs to create “rows” in your layout. Your header may be one container, your content may be another, and your footer may be yet another. Or, you may have many more. Don’t think can only have one container.
Remember that you don’t need to use all of the pieces of Blueprint CSS. For example, if you’re not doing a grid-based layout, you may not need grid.css. But, reset.css and typography.css may still be useful to you.
And finally: don’t ever edit Blueprint’s files! A much better practice is to include your own stylesheet and override Blueprint. Editing Blueprint’s CSS files will make upgrading to the latest version of the framework much more difficult. Keep your work separate from the framework.
The bottom line
Blueprint has proven to make Blue Flavor more efficient at creating HTML and CSS templates from our designer’s comps. It has has already solved many common browser rendering issues for us, so our CSS requires less debugging in older and less standards-compliant browsers. It does take a couple of hours to learn and really understand the framework, but once you do, the efficiency of using it is really impressive.
Besides making us faster at initial HTML and CSS development, it also helps us to be doing things in a consistent way from developer to developer. Since we’re all using the same framework, I always understand what’s going on right away when I have to poke at someone else’s code. This, too, is a time-saver.
Ultimately, the less time we can be spending on HTML and CSS coding, the better we can serve our clients. After all, HTML and CSS is only a very small portion of what most of them are paying us for. It’s much better for both us and them if we can be spending our time solving design problems, helping them with their brand, and strategizing about how they can give their users the best possible experience.
This looks very cool.. but it crosses what I believe is a dangerous line. It has you putting style data in the your HTML, which is a slippery slope.
The HTML, including IDs and Classes should describe the structure of the document, how it looks is up to the CSS. Mixing in class names that explicitly describe appearance breaks this division.
Maybe I’m a little anal about this sort of thing, and I’m curious to see what other people think.
Either way, this is a cool style sheet, even just for educational purposes.
Great write up Jeff. My brother and I have been using Blueprint quite a bit in our small studio. Big thanks to you, Nathan, Christian, Olav and the contributers.
One note. We are fairly certain that the Grid Generator created an incorrect grid.png file. The column and gutter widths were off by one pixel. Has anyone else experienced this?
I’m surprised they don’t namespace their css. For example, classes such as.column and .container… It seems too likely that other frameworks (javascript, etc.) or people would use these same names.
Matt, I think you can read Jeff’s opinion on your concerns in his own blog. In my opinion he makes some pretty good points: http://www2.jeffcroft.com/blog/2007/aug/09/myth-content-and-presentation-separation/
Matt:
Remember BP is only a framework. The idea is to give you the ability to quickly set up a grid and worry about important areas such as design and what not.
If you want to make the code more semantic, all you have to do is just copy+paste the code from grid.css into your individual div ID’s when you’re done. Then you can have the best of both worlds.
eg. id=’header’ class=’column span-12’ can be edited in your css to say. #header {float:left; margin-right: 10px; width: 470px;} and BAM you have semantic code. Once you know the BP CSS is fairly easy to do.
Just a couple of questions:
You say not to edit Blueprint’s CSS files but instead override rules with your own, but doesn’t that lead to larger CSS file sizes than necessary?
From reading your article and looking at the generator, Blueprint seems very fixed-width/pixel-specific. How does it handle fluid/elastic layouts?
Jeff:
Great article. I wanted to add that to generate guides based on a grid in Photoshop I use Andrew Ingram’s gridmaker:
http://www.andrewingram.net/articles/gridmaker_reboot/
I was getting ready to write this script myself but found that someone had already done it for me :)
Very nice article, Jeff. I’ll link to this from the Blueprint site, since a lot of people have been asking for such tutorials lately.
And if you have any ideas or suggestions, maybe fixes you guys have implemented at Blueflavor, don’t hesitate to drop me a line.
After all, BP is as much your work as it is mine. :)
Regarding the slippery slope: this too was my initial reaction but I’ve since reversed course. I think using “compound” class and id names is completely appropriate and semantically sound. The important point is that you maintain a semantic structure while incorporating Blueprint.
So you might have a div whose id=”secondaryContent” and class=”column” and you can wake up in the morning without feeling guilty about last night. Yes, you’ve compromised your rigid principles somewhat by including a presentational label, but you haven’t destroyed your page’s semantic structure. The important point is that you maintain your html’s integrity and do not create your grid with a sea of divs.
I still have yet to decide whether I think Blueprint, or CSS frameworks in general, would work well with my workflow (check that alliteration!), but I do appreciate the points that you brought up. There’s only one thing here that bothers me:
<blockquote> <p>Ultimately, the less time we can be spending on HTML and CSS coding, the better we can serve our clients.</p> </blockquote>
Maybe I’m reading too deeply into it, but since when is HTML and CSS considered <em>not</em> serving clients? Front-end code is definitely problem-solving, and deserves as much time as strategy and design.
@Charles: Yeah, namespacing might have been nice. Unfortunately, I think it’s too late to go there, without having major backwards incompatibility.
@John:
@Dan:
In re-reading that, I may have been slightly unclear. I completely agree with you that front-end code deserves plenty of attention and is every bit as important as the other aspects of the project. My point was simply that any time we can find a way to streamline one part of the process (without sacrificing quality, of course) means we have more time in a project’s budget to focus on other things. Our clients pay by the hour. In my mind, we have two big responsibilities to them (in this order):
Blueprint seems to help us achieve number two.
Let me also say this (I should have said it in the original post): it’s not so much Blueprint that saves us time as it is the simple concept of having a library of CSS patterns that we can reuse and have each person on the team be familiar with. Blueprint provides a good library, but you could just as easily build your own, if you prefer.
Hey Jeff,
A great article, as always!
Just so I’m clear, do you put Blueprint into production, or do you use it just for POCs and/or rapid prototyping?
I find it difficult to resolve the dichotomy when using frameworks/libraries (I’m a big fan of Yahoo’s YUI), that is: you have to balance the benefits (convenience, speed of development, etc) with the costs (unused code, unnecessary client-side performance overhead).
What are your thoughts on this?
@Dan: We’ve used it both for production work and for rapid prototyping.
My feeling on the dichotomy you refer to is pretty simple: the benefits drastically outweigh the costs, for most projects. Unused code? Client-side performance hit? Meh. It’s CSS. The entirety of Blueprint weighs in at under 30k and is sent once and then cached by the browser. Most photos on web pages are larger than 30k. Let’s assume you can write the CSS without using the framework in 15k. Is a one-time-per-visitor transfer of an extra 15k really worth several hours of your development time?
For me, the answer is almost always no. A few exceptions might be:
There are always trade-offs. You’re totally right: if you use Blueprint, YUI, Django, Rails, or any other pre-fab development libraries, you’re going to have unused code. In the case of CSS and JavaScript, that code gets sent to the user. Everyone needs to be aware of that and evaluate whether or not it’s a major issue for a given project. I think, in the case of BlueprintCSS, you’ll find it’s usually not.
On the other hand, too often frameworks are used by novices as a shortcut to complex layouts. Advanced CSS users should be using frameworks to streamline code and simplify the complex.
Almost makes you think a scrubber tool that parses your id’s & classes and removes the unused ones from the BP style sheets is a good idea.
@Jeff: I think, if you try using the framework for a real live site, you’ll find that you use 90% of the classes. There isn’t a lot of “fluff” in Blueprint proper (although you can argue there’s some in the optional plugins). It’s unlikely such a parser would actually find much to remove, on most sites.
I’d say my only concern for having a framework like Blueprint would be that one should learn how the “tricks” of CSS before, to understand what it is that Blueprint is doing.
I think we all know how much we learn as time progresses, and I know my CSS and HTML are much cleaner now then they were a year ago, or even 6 months ago. And (hopefully), I’ll be better in the future. You can always learn.
I just fear a new “generation” of designers coming along, picking up Blueprint - or something similar - and hacking together non-semantic sites.
Then all we’ve done is replaced tables with extraneous CSS. (<tr colspan=”12” replaced with class=�column span-12� isn’t necessarily a great thing.
This isn’t to say Blueprint is a bad thing, just waving a caution flag.
@Dave Simon:
What you are saying is true with any framework, library, or tool that is designed to make your life easier. Look at all the people who got excited by the Rails hype and dove in without first understanding MVC, object-oriented programming with Ruby. What happened to them? Well, they built Twitter. And it was so porrly done, it wasn’t able to scale at all. Then look at the stuff 37signals has built with the same framework. It works great and scales well. Why? Because they understood how the framework works before diving in.
Framework and libraries aren’t a magic bullet. You can’t just plug one in and be off to the races. You do have to learn them. It’s why I said, in the original post, to be sure to read all of the code and fully understand how Blueprint works before jumping in too deeply.
Framework misuse will always be rampant — it always has been, and always will be. But it’s not the fault of the framework, it’s the fault of lazy developers.
Wow, risky maneouvre giving out this info, but thanks!
@Dave Simon (Deal’s Gone Bad…what?!)
I find it funny that you say that users should “…learn how the ‘tricks’ of CSS before, to understand what it is that Blueprint is doing.” This is exactly the same attitude that I take to people who are looking to user frameworks like cakePHP, Django, Rails, et. al. Reading your comment, I was annoyed. Perhaps I should revise my own opinions and be annoyed with myself?
I used blueprint for my site http://www.danielfischer.com I think I did a pretty good job with it!
It struck me today that Blueprint is less like a framework and more like scaffolding (in the Ruby on Rails sense). Scaffolding in Rails gives you a framework to get you quickly started, but you eventually strip it all down and end up with something more specific and hardly resembling the original, auto-generated code. This is how I find myself using Blueprint. Its conventions make life much easier when working on several projects and it solves most of the boring stuff that we really shouldn’t need to be dealing with these days, namely browser compatibility stuff. The fact that Blueprint encourages non-semantic class names is a red-herring. Once you’ve finished your design you can change the class names quite easily. Plus HTML allows the use of multiple class names which provides the ability to include a semantic name in addition to the non-semantic one. So what’s the problem? I prefer pragmatism over purity and it seems Blueprint provides just the right sort of compromise.
Charles: While I totally agree with you that Blueprint can be used like Rails scaffolding (that is, to quickly get something together, and then go back and clean it up later), I also believe Blueprint is completely appropriate for use as final, production code.
It is definitely great for prototyping too, though! :)
Just use YUI CSS people
Blueprint CSS definitely looks interesting: I’m getting bored of reinventing the wheel each time, too. I bow before thee, O’ Gods of Open Source!
I’m also considering YUI CSS and wondering if anyone has an experienced opinion, hopefully someone who’s worked with both of these frameworks. I haven’t used either one, but I do have some first impressions.
What I find more attractive about Blueprint rather than YUI are the following “ugly” points that struck me about YUI:
YUI grids are built by splitting “rows” (.yui-g) into exactly two units (.yui-u). If you need more columns, it requires that you add deeper nested markup with more yui-g’s inside other yui-g’s. This sounds totally unintuitive, and is definitely less semantic & flexible than Blueprint’s “span-x” classes.
YUI seems to require more element nesting (wrapper divs), in general.
YUI uses ID hooks for key elements (#doc, #hd, #bd, #ft). In my opinion, IDs should be reserved for your own semantic definition of document parts, not the framework’s.
I’d love to see an intelligent comparison of both Blueprint and YUI CSS.
just started using blueprint and i love it!
it has saved me countless hours retyping the default values for my css files :)
can u guys post up examples of websites you did using blueprint?
It would really help out a lot if we could see different implementations
Thanks!
When are liquid layouts and png transparency for IE5.5 due?
@Robert: I’m not sure — you’d have to check with Olav and then Blueprint team.
Thanks, having fun with this trying to rebuild a website using this. But confused about when I should use nested divs:
div column span-24 div column span-8 div column span-8 div column span-8 last
and when I should use this:
div column span-8 div column span-8 div column span-8 last
ie. when should I enclose a row of columns in a container div or parent div? Both seem to work?
Perhaps you could provide some more examples for the slightly confused.
Hello this is a text for a long text please feel free to delete this comment, so here is the teeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeest the template still look good??? chears.
What if I want to use columns with border? If I do that, the defined widths for columns does not work because column’s width increse 2px (one each side).
We just released a new WordPress theme built with BluePrint CSS. Would appreciate some feedback.
You can get more information here: http://www.slipfire.com/sf-blueprint-wp-theme-52.htm
Thanks Steve
Thanks for very interesting article @ comments. Blueprint is ok.