He hablado otras veces sobre los frameworks CSS ya que, bueno, mi perspectiva, y de hecho el código que uso, es algo distinta desde que escribí esta entrada. Aunque creo más importante mencionar que mi opinión es totalmente al contrario respecto a frameworks de otros lenguajes -por ejemplo, soy casi fanático de Zend Framework- y lo resumiré en lo siguiente:

En lenguajes de programación, trabajando en base a estándares y con frameworks establecidos, me atrevería a decir que la productividad aumenta casi un 100%. El problema es que para CSS no es este el caso porque CSS no está pensado para generalizar un resultado sino al contrario. Por ejemplo:
No hay o no debería haber una forma única de estilizar una imagen o un párrafo, ni tampoco en la forma de hacerlo. En cambio, sí que la debe haber, o debería haber, para renderizar una página, llamar a un método remoto de una API, intercambiar datos de cierto tipo…
Es decir: un framework es un marco de trabajo para una tecnología y ya está. Su utilidad depende de esa tecnología y no se puede pensar que si se tienen reservas sobre un framework de una tecnología en concreto también se tienen de todos los frameworks… no es lógico ;)

Por eso, cuando he hablado de usar algo genérico en CSS al final se reduce a reglas y elementos realmente muy genéricos, y más en concreto y útil, a una forma de trabajar, de codificar, de organizar hojas… Pongamos por ejemplo:
¿Cuántos tipos de diseños estructurales puedes querer tener?
3,2,1 columna, más cabecera, pie… flexible y líquido o fijo. Bien, más o menos unos 6 diseños que se pueden generalizar. Pues aún así, cuando hablamos de CSS, estamos siendo estrictos siempre ya que el límite es la imaginación: dos cabeceras, tres, ningún pie, dos, dimensiones de los elementos estructurales…
Con el tiempo, cuando hablo de frameworks CSS a la cabeza me vienen muy pocas reglas, siempre semánticas eso sí, para estandarizar, y muy pequeñas como por ejemplo .error, .warning, .important etc, para si acaso un párrafo o una frase.
Solo he dicho que, al menos a mí, me viene bien tener ya montado un sistema base para luego ir ajustándolo y adaptándolo, además de una estructura y organización más o menos estándar en las hojas. ESTO sí creo que se puede estandarizar.

Framework CSS:
Desde que las resoluciones de pantalla son tan amplias y variadas como lo son hoy en día la cuestión es que nunca uso diseños fijos. Es más, tal es la situación que hace tiempo que existe una versión no oficial de plantilla Blueprint para diseños líquidos.
Esto en relación al otro framework que me comentas: 960 no sé qué. Y es que, sinceramente, su mismo nombre expresa el anacronismo de su técnica y, ojo, no es comentario despectivo sino realista: es la situación actual en un mundo de 1260 casi mínimo en escritorio, pasando a los handheld englobando aquí PDA’s, móviles, etc, en el extremo opuesto en cuanto a resoluciones.

Por otra parte… imagino que cuando sigas diseñando tus sitios irás descubriendo la necesidad de usar uno propio pero de forma muy genérica. Mi progresión en todo caso ha sido un paso de: reglas semánticas; perder el foco usando reglas genéricas por todos lados -esto son los frameworks CSS-; para volver a las reglas semánticas que, en mi opinión, es lo que debe ser el marcado estructural a parte de estructural, claro.

Frameworks en otros lenguajes (PHP):
Pero me gustaría hacer hincapié en la cuestión de los frameworks y la forma de entenderlos. Esto es:
Aunque por concepto puedan serlo, un framework CSS tiene más bien poco que ver con un framework… casi de cualquier otro tipo.
Es decir, un framework CSS, tal y como está el patio tiene más bien poco sentido porque, precisamente, CSS personaliza, estiliza, hasta los límites que un diseñador tenga o se autoimponga. Es decir: se generaliza, se estandariza una técnica que precisamente está destinada a todo lo contrario: la riqueza de estilo.

O sea: es de esperar un que diseño CSS esté personalizado incluso caprichosamente, y eso es lo que espera un diseñador que trabaje en grupo por ejemplo. Ojo, no hablo de la forma de escribir una sintaxis o de estructurar hojas de estilo, etc.

No ocurre lo mismo con un lenguaje de programación en donde los estándares facilitan el trabajo en grupo, la mantenibilidad y la organización. De hecho, es una de las ventajas que muchos mencionan de Java sobre PHP. En Java encuentras servelets, portlets… que poco a poco van llegando también ahora a PHP.

En cuanto a los frameworks, me puse a leer sobre blueprint, me gustaron las primeras impresiones y como siempre, te encontras con opiniones como la tuya que no son las mejores. Ya me paso con CodeIgniter en php. La solución es bajartelo, probarlo y si te sirve en tu caso, bienvenido sea.

Para investigar, otro framework (o libreria) css que use alguna vez es 960grid. A diferencia de Blueprint, se enfoca en el layout, en la estructura. Se basa en la idea de la flexibilidad de diseños de 960pixeles de ancho. La verdad que esta bueno, aunque hay que trabajar bastante el tema de tipografias y otras cosas.

Un saludo y felicitaciones por tu gran aporte, seguro lo voy a seguir y adaptar a mi trabajo!