Yes, but I'd bet that many UI developers have built up a set of common selectors and techniques to make this easier. A framework just codifies that practice for use by others.
An advantage of using a framework is that a good one will not just get you want today, but make it easier to change that layout tomorrow when the client has new opinions.
If you use something like 960gs, for example, it is trivial to create any of the layouts shown for Primary. But it is also trivial to add or remove or grow/shrink subdivisions with 960gs, whereas Primary looks a bit hard-wired.
There is no such thing as good CSS framework. If you are using 960gs you are just littering your code with "grid_2 suffix_4" kind of presentational crap. What's worse to change layout you must change the html (class names), instead of tweaking just CSS.
In short — those who don't know CSS shouldn't use frameworks, those who do know don't need them.
"In short — those who don't know CSS shouldn't use frameworks, those who do know don't need them."
Whatever.
I get the results I want in an effective and efficient manner, using simple, direct markup I find easy to follow and easy to maintain. And it will be easy to follow and easy to maintain by the people I turn it over to, who typically do not employ anyone who has to time or inclination to devote themselves to the minutiae of reliable cross-browser sanctimonious markup purity.
YMMV, of course.
The horror of littering code with presentational crap (hyperbole much?) means, in real life, pretty much diddly squat, because patting oneself on the back for hand-crafting pristine HTML + CSS has near zero value relative to other concerns.
Some developers prefer to treat software development as a craft, and display craftsmanship in the final product, even if nobody else will ever appreciate it.
