CSS grids are trivial to write. They consist of three major declaration types:
.row { width: ?px; clear: left; }
.col-1, .col-2.... { margin: ?px; float: left }
.col-1 { width: ?px; } .col-2 { width: ?px; }
Why do I bring this up? Because it is so simple to write these, it almost never makes sense to use a framework. If I ever want a grid for a particular project, I write it custom with a little help from excel.
This allows me to build mini-grid frameworks for whatever container width I need. This way I don't abandon separation of content from presentation across a whole site -- just on a particular page.
I really don't get why people feel the need to reinvent row/column structures when there's a more reliable, better option built into every browser for the past decade.
"Tables are for tabular data" just strikes me as ego, and while I've seen a ton of flaky work-arounds with DIVs, I've rarely seen one that worked well and didn't force needless compromises (extra white-space for dynamic content to ensure you aren't bitten by overflow issues or have to clip content to fit the design).
There's a tool that does the job. It works in every browser that's ever mattered. It does it most simply with the least side-effects. It uses about the same amount of "non semantic" markup (.row and .col are separating presentation/layout? That's a weird definition of the phrase). It's reliable, it's predictable, it doesn't come with side-effects (let me just update my global .row class here and, d'oh, I've broken half the site because I focused on minimizing styles rather than coding defensively keeping likely client requests for tweaks in mind).
Build a whole site out of tables? No thanks. Use tables for dynamic content of variable height that needs to be maintained in rows and columns? To do anything else doesn't serve the interests of the client or your own business.
Redeveloping tables with divs and .row/.col classes just to avoid using an element called "table". One of my greatest frustrations with designers.
It's not fun to have to go in and fix people's shoddy work they spent days not getting right just because they couldn't put the business ahead of their ego.
If you really must avoid tables for whatever reason, lists are almost always a better choice.
I do agree with the spirit of this comment though. CSS Frameworks are the Microsoft Frontpage of modern web design.
Firstly, the likelihood alone that any given CSS designer who follows up on your project actually understands the framework is not high. These frameworks make a very small subset of CSS people write. Certainly not a large enough subset for you to make that assumption by any means.
Secondly, this is a poor analogy because we're talking about 3 CSS classes- by no means a "wheel". I am curious as to what circumstances you would really save any measurable time using a CSS framework.
You shouldn't, table is not an element that should be banned from the web it is actually extremely useful. The problem with table is when you use it for layout it creates some unwieldy markup that it is better to just use css.
Some designers however seem to use divs for tables and it just looks silly and ends up being overly complicated.
CSS frameworks are especially useful when you're using Sass & Compass (compass-style.org) because you can completely bypass having to add all these ugly and tedious class names to your HTML. Instead you can make a few mixins out of the framework's code and stick them right into your css. Your HTML & CSS will be semantically cleaner and easier to maintain if you want to make changes in the future.
I never understood what these CSS "frameworks" are supposed to do for me. Define the width of the two columns on my page? I just don't get it. This is a serious question, I'm not mocking/trolling, so I'd appreciate somebody enlightens me.
edit: thanks for the answers guys. I still don't get it though, it's just a couple of lines of CSS in this "frameworks". Oh well, I guess I just don't get it ...
I'm a web developer, but not a designer, and not hugely proficient in CSS. I understand the basics, but it often takes me a while to get things to look the way I want them.
For me, grid frameworks were a revelation - they let me, for the first time, quickly lay out the site with very little pain. Using a framework, I sketch how I'd like the site laid out, and then it's a simple matter of writing a bit of html and adding a few classes to get the layout I want. Working from zero is much harder for me.
From my perspective as a designer (I make this disclaimer since I could be talking out of my ass), these CSS frameworks seem like an easier way to implement a grid system in a web page. I don't have to define the width of the grid or gutters, I just specify how many columns per row I want. This makes the act of laying out content for me faster than having to code this from scratch.
the real purpose of this, and blueprint, and 960.gs is to give you a pre-defined set of layout elements to help in rapid prototyping. The idea being that these frameworks ahve been tested across all browsers.
so in theory (or practice) you can rapidly whip up multi-column layouts without worrying too much about it.
note that these frameworks are often overkill, and come w/a lot of unnecessary weight/code for lots of people.
The frameworks are great for mocking sites up: instead of modifying CSS for every layout you test the framework gives you a few classes with sane defaults that you can easily switch between to align and re-align your columns.
My typical workflow is to include a stylesheet that defines a basic grid and use that when working on the design. Towards deployment I write the grid to my main stylesheet using the elements' proper class-names and ids.
CSS Frameworks are especially useful when you have multi layout page. With few lines of CSS code you can have some complex layout. Other thing is reusability write once use it many times. Here is what you can do with one line of CSS http://www.vcarrer.com/2009/06/1-line-css-grid-framework.htm...
I like the fact that more people are trying to incorporate baselines into their grid. This is another one I found (http://baselinecss.com/) but I much prefer the one in the OP.
So, this is a neat idea, but the way css is designed (i.e. half-leading model) makes generalized baseline alignments completely horrid because you end up doing all these positioning gimmicks based on the exact descender depth of the font you're using. At that point, you're really designing for the font which sort of defeats the generality/convenience of css.
I don't think at the time it was designed there was a sense that anybody would actually want features like actual baseline alignment (i mean, look at the extent of UILabel's typography options for a good example of this sort of present-day rationalization) I've nearly given up on having any semblance of generalized baseline alignment in css like i do in, say, indesign, which although horrid, at least got that part right.
That said, if you want a good argument against a strict baseline grid i'll supply one and a half: derek birdsall1's notes on book design[1] and mine:
When i started working through my mfa i had completely drunk the grid kool-aid from Samsara, Elam, Bringhurst and (natürlich) Müller-B. I was obsessed with vertical grids and i used them much to my detriment (because i was blindly plugging away). My shit looked mechanical which is not really me at all. Then i met another designer who said, in passing: "who really uses grids? You make shit look good. When you're done, you tidy it up with a grid if the spirit moves you.* It'll probably already be on some grid, everyone's brain does that, and your post-rationalized grid's practically ready-made. how cool is that?"*
Now, this sort of presumes you can make shit look good which is a tall order, but really it means following your gut and possibly using a grid to keep it in check. If you start with a fixed grid, you limit many of your options from the outset because you're trying to fit stuff into these little squares.
Of course, this takes lots of practice. Practically speaking, grids take much of the choice out of things. If you need to make something that looks cool fast, rip one out of Müller-B and plug away. It will look awesome. Otherwise, loosen up, have some brown liquor and design away until you're happy or trashed or both.
I think for a general designer, using a grid is probably the best method because... it takes a lot of skill to actually break the grid in a method that is still readable yet a well-styled execution.
I definitely upvote the notion that using a very fixed grid limits options, especially if one is also working with a vertically fixed grid. If I think about the most memorable websites, they usually break the grid.
In many ways, you've actually convinced me not to use this grid.
Baseline is where the bottom of a text character sits. Sidenote: Parts of a character that descends past the baseline (characters: y, p, q, j) are called descenders.
In graphic design, baselines are used to align content in different columns so that they line up with one another. For example, if you read a magazine article and see two columns side by side, they should share the same baselines.
This is especially useful when you have elements that make columns shift positioning. Let's say on one column you have some text and on the other, you have an image that pushes down the second column. How do you align the second column? Most people would just look at the padding between the image and the second column of text when in reality, it's probably best to also look at whether or not it's sharing the same baseline as the first column.
Baselines are a very nice touch, but always use judgement and don't be afraid to step out of those guidelines (or adjust the design) when you need to.
The Baseline homepage is generally aesthetically pleasing, but goes a bit overboard: the top-right introductory text sticks out sorely with its font size : line height ratio.
True. I mean, on the startup I'm working on (http://www.votereports.org), I threw away baselines on the instructional area largely because I wanted to make the page seem more dynamic and very different from rigid designs I've seen other people do.
Baselines traditionally make a lot more sense in print design (especially books). But it's nice to have this option on the web.
I'm not the OP but I think it is because the class names being used are not semantic in terms of the content. Instead they contain information about the layout of the page.
This makes certain types of change messier. For instance, if I have some CSS class called `quotation` that is used in various pages of my site, I can change the style of those divs or whatever in one edit of a single CSS file. However, if instead those elements all have the class name `sg-5` and I want to change them all to be `sg-7`, I must go and edit every page that contains instances of said element. And, speaking from personal experience, I will probably make a mistake or miss some cases when doing so.
I appreciate the sentiment, but this doesn't seem as big of a deal now. You can have a semantically structured page, then using jQuery or more advanced CSS selectors cherry pick elements and assign classes without touching the html.
I'm an advocate of frameworks, but only for fast prototyping. Nothing beats designing in the browser using Haml (http://haml-lang.com/) and Compass/Sass (http://compass-style.org/) in conjunction with Static Matic (http://staticmatic.rubyforge.org/). Compass has blueprint integrated and using mixins you can avoid having an un-semantic mess in your Haml/Html.
Truth be told though, I use less and less the blueprint features in Compass each day. I find grids amazing for Photoshop (I generate a grid like the one in this thread for every comp) and Keynote/Wireframing/Initial Prototyping (I use a simple broad grid to do wireframes in Keynote), but really don't belong on my markup!
I like the idea of designing with a grid in mind (I use the 960 grid for many of my projects), but I never use the CSS framework to convert it to html. I just don't see the point, every design is unique and handcoding is always more perfect/cleaner, yet doesn't take much longer, if at all, to write.
.row { width: ?px; clear: left; }
.col-1, .col-2.... { margin: ?px; float: left }
.col-1 { width: ?px; } .col-2 { width: ?px; }
Why do I bring this up? Because it is so simple to write these, it almost never makes sense to use a framework. If I ever want a grid for a particular project, I write it custom with a little help from excel.
This allows me to build mini-grid frameworks for whatever container width I need. This way I don't abandon separation of content from presentation across a whole site -- just on a particular page.