Wondering about “CSS Frameworks”.

I have not personally used them, but that’s primarily because that’s part of the process I came through on the way to web designer. It’s not that hard for me at this point to code css, much like your skill with RoR.

Over far too much trial and error I’ve learned what works and doesn’t for the different browsers and platforms and developed my own rules for things I don’t do because they’re hard to work consistently across the many combinations, or might require hacks (which would then fail later), etc. I now design around these rules up front. The biggest thing I did was let go of pixel perfection and plan for growth or stretching in the design.

If I were doing it all again, I think I’d still go this route, but allow for using the frameworks when the design was fairly intense — think a columned newspaper design or portal page where you might want to drag things around (and thus need tight integration with a javascript library). These are the places where I just beat my head against the wall for far too long. But, most designs don’t need this level of sophistication. I think most can get away with far less, skip the overhead of the framework, and have semantically better content underneath.

I’ve used YUI CSS grids on a couple side projects, and I’ll never go back. In fact, we’re planning to move the Library’s site to a YUI-based model over winter break.
I’m probably not as advanced in my CSS knowledge as David or others, so I like how YUI basically takes care many of the cross-browser issues. That way I can focus on content and functionality, and YUI handles the layout and other ‘under the hood’ details. Not entirely sure how it would fit in with RoR, but it works well for our shop (PHP/jQuery).
There’s a pretty good video of a Yahoo engineer describing the YUI CSS foundation on this page.

I’ve thought about adopting a CSS framework in the past but never went ahead with it. The obvious model, to me, are the JS libraries like jQuery (which you’ll pry from my cold, dead hands). The key benefits are the same that are offered by CSS frameworks–rapid development time, project-to-project consistency, browser compatibility, helper methods for common tasks–with a lot of the same costs–having to code in one particular way, hitching yourself to someone else’s star, download size, etc.

But the polarity is switched. With a JS framework, the benefits seem huge to me (particularly the browser compatibility and animation helpers). With a CSS framework, it’s the costs that seem huge (loss of semantic structure, insinuation that each website is not a unique and beautiful butterfly) and the benefits kind of meh. In particular, browser quirks with 98% of CSS just don’t seem to me to be that big of a deal (say, compared to all the code required for cross-browser event handling). Yes, a beautiful column layout can take days and days to implement in IE but you only have to do it once–instead of lugging a heavy framework from site to site, I can just copy-and-paste my last beautiful column layout as a starting point (or else just Google for an ALA article about beautiful column layouts). There’s definitely 2% of cases where you’re doing something so totally awesome and it seems absolutely impossible in IE , but those are the 2% of cases that something like YUI is leaving behind anyway.

Mostly, though, I’m just a big semantic structure geek. And nailing that crazy design with as little markup as possible is the fun part!

Donald beat me to the punch on this one, but you’ll find us mostly in agreement over this issue: I like the idea of css frameworks, but not the overhead or lack of syntax customization that they bring to the table. The argument for css frameworks—specifically cross-browser compatibility and rapid prototyping—assumes that a developer (or studio, as is our case) has no pre-defined styling conventions of their own. We have our own brand of a css reset to pseudo-level the playing field, and a few projects ago, Donald came up with a magnificent way to handle multi-column layouts using simple classes that can be recycled ad infinitum provided that you change the dimensions to your needs for any given project. I have flirted with YUI a few times, but honestly never quite fell in love with it. Don’t get me wrong, I totally understand and sympathize with those that praise it—my experiences with the framework simply reminded me that I enjoy the freedom to utilize my own conventions and ideas in regard to custom-built sites and applications, as it makes the process more personal and less mechanical. We are artists in fact, in our thought process and problem solving skills, if not in the aesthetic sense.
As a point of comparison, jQuery, on the other hand, makes life infinitely easier—and more enoyable—due to the massive shrink in code that needs to be written to accomplish virtually any behavior, as well as all of its really neat built-in behaviors. Just a few days ago I was doing some quick maintenance for an old client, and took a stroll down memory lane with some old JavaScript that I had written pre-jQuery. There was this super simple slideDown more/less effect that I had written from scratch without a framework, which was ten or so lines of somewhat vague script—accompanied by a complete lack of easing, making it visually lackluster beyond its functionality. Just for fun, while doing their update, I ripped out this old js and rewrote it with jQuery in a neat four lines of scripted poetry, including some fancy easing. This kind of change—coupled with the fact that jQuery actually makes JavaScript a whole lot more fun to write and tinker with—completely justifies the overhead of the library. Comparing this cost/return with that of YUI… well, let’s just say that jQuery rode off into the sunset without a scratch.