I’ve been thinking about this quite a lot recently.
OOCSS
I like OOCSS. When I first read the slides it made sense, make re-usable components with css, use multiple classes for variations.
Another similar concept is Jonathon Snook’s http://smacss.com/ which I haven’t read yet.
cluongo, flick through the slides or watch the video. If there’s nothing in there you want to use, that’s fine. It’s not a joke though.
CSS classes for Layout
This is quite a different topic to OOCSS, where it overlaps is that both OOCS and layout frameworks encourage you to re-use code without having to write more CSS and to put more presentational classes into the HTML.
I agree semantic markup is important, semantic class names are important too, you should definitely use <p class=“info”> as opposed to <p class=“yellow_info_bar_with_bold_text”></p>
But, layout doesn’t fit nicely into that category.
I find layout is quite often closely tied to the content - often you change the layout to accommodate changes to the content.
For most simple sites where there isn’t a huge amount of variation between layouts you can get away without layout classes.
As the site grows if you don’t have some layout classes then your stylesheet will continue to grow with every slight variation - This is one of the major issues that OOCSS was trying to address.
But it’s not semantic!
It makes no difference to the experience or accessibility of the final page. I’ve stopped caring about this.
People have started hiding the fact that they are tying layout to content by using mixins which just copies floats / widths / gutters into the different selectors.
There’s no presentational classes in their HTML so they feel good about it, it’s just that it’s duplicated on mass throughout the CSS, and it’s only a cover.
Mixins will eventually be available in CSS, so duplication won’t be an issue.
Presentational classes mean that you can’t change the design later on without changing the HTML
That’s true, but that’s not a problem.
With a serious re-design you’re always going to be re-working the content & layout at the same time.
I’ve never had the case where a full redesign didn’t mean shuffling bits of HTML around.
@John_Betong, I have a similar set of classes I stick with my reset, though I object to these three because they are strictly presentational and I can’t think of good reasons for them.
.bgr {background-color:#f00} .bgg {background-color:#090} .bgb {background-color:#9ff}
.fwb {font-weight:700}
.tdn {text-decoration: none}
But, to be honest there are cases where I make exceptions to the rule, for special feature buttons I do have classes like “blue-btn”, “red-btn”
Here are my utility classes
.fr { float: right }
.fl { float: left }
.cl { clear: left }
.cr { clear: right }
.cb { clear: both }
.ib { display: inline-block; vertical-align: top }
.clearfix:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}
I have also used fluid grid’s like this. hold the torches and pitchforks
/* layout */
.fluid > div { float: left }
.fluid .quarter { width: 25% }
.fluid .half { width: 50% }
.fluid .third { width: 33% }
.fluid .fourth { width: 25% }
.fluid .fifth { width: 20% }
.fluid .sixth { width: 16.5% }
.fluid .two-thirds { width: 66% }
.fluid .three-fourths { width: 75% }
.fluid .two-fifths { width: 40% }
.fluid .three-fifths { width: 60% }
.fluid .four-fifths { width: 80% }
.fluid .inner { padding-right: 20px }
.fluid > div:last-child > .inner { padding-right: 0 }
@media only screen and (max-width:480px) {
/* linearize grids under 800px */
.fluid > div { float: none !important; width: 100% !important }
.fluid .inner { padding-right: 0 }
}
I’m interested in hearing others opinions on this, I think there’s good reasons for layout classes.
Especially when you use grids extensively.