Shared publicly  - 
One thing I’ve started using a lot more of over the last year is classes. Dozens of short, tiny helper classes. Instead of applying one ID or class to an element, I’ve started using a handful of smaller ones in conjunction with each other to get the same result.

A few minutes ago—largely as a proof of concept—I wrote this HTML:

`<a href=/login/ class="btn btn-rev btn-lrg giga go brand-face">Log in</a>`

Although a very exaggerated example, it felt good.

Using lots of tiny classes like that is akin to eating at Subway; instead of ordering a sandwich as a whole you can make an almost infinite amount of combinations of sandwich by combining the smaller parts—the ingredients.

By breaking a sandwich down into smaller bits you can quickly and efficiently create a multitude of varieties of sub. This is what class based builds are like. Instead of:


we now have


and that is awesome!

Don’t like tomato? It’s easy to leave it out…

Class based builds are like eating at Subway (only nicer).
Dan Claydon's profile photoHarry Roberts's profile photoAdam Hepton's profile photoMax West's profile photo
I get a feeling that your post / this approach might get a bit of a 'classitis' response from the "Best Practice Brigade", but I stand with you 100% on this one.

I'm sure you've had a similar experience, but as projects get larger and more people become involved, keeping HTML lean is often at the expense of clean / maintainable CSS.

The 'bit-by-bit' class approach also sits pretty well with pragmatic font sizing and OOCSS

As a final point, mainly to anyone who mentions bloat...if you've blitzed a site with minification and caching; the speed difference of the extra classes is negligible.
I really like this idea. Just one quick question, do you still use IDs in addition to classes? If so, how do you decide between ID and class for a specific element?
Nice analogy Harry, I intend to copy it. I do the same, but I also include the ID. Often it does nothing apart from make the HTML more readable. You could have a stack of sandwiches that all have a similar but slightly different class list, however it doesn't identify them individually as "Tuesday's Lunch" or "Thursday's Midnight Snack". It instantly makes it clear to anyone reading your html exactly what this .wrapper actually is. Yes it's a .wrapper, but it's also the #footer-wrapper.

Also if you ever do any Watir testing (you should, it's taught me a different way of thinking about html structure), ID's make your life so much easier.
I take a similar approach but I don't use as much as dozens of classes. As Jason points out it could feel like a bit of 'classitis' and although I don't see a problem with that if used correctly, I do see a small problem in managing class names but easily overcome with some planning.

One actual pitfall I found with this approach is when using ems or percentages to define things for example widths, margin etc because of the nature of how they work.


<header style="font-size:2em;">
<button class="font_2em"></button>

<section style="font-size:1em;">
<button class="font_2em"></button>

Using this approach to define the same size of font doesn't work as expected as the base of each size of the header and section is different. Although you could just avoid using any css properties relating ems.

I think this approach is extremely manageable, works well for quick changes to a design and makes sense to build a system for styling web pages for everyone.
I don’t use any IDs at all in CSS ever any more. They have no advantages over classes, only disadvantages. It’s a major point of contention but yeah, I just avoid IDs 100% of the time.
In CSS, no, never use IDs IMO, but in HTML, they have some collosal advantages.
I've been trying to weigh up the pro's and con's of OOCSS and I like the modular approach to it (I'm OK with the large number of classes now!). Has anyone used this extensively on production websites involving a team of developers?

I'd be interested to see how it worked out, particularly with those that may not have worked this way before.
I used it on a lot of aspects of but I was the sole CSS guy on that. I’ve written docs for the team but I’m still the main CSS dev.
Thanks for the input, all. That is an easy way to differentiate: classes for CSS, IDs for HTML. I have to say that IDs are an enormous help for auto testing, so I'd be loathe to give them up entirely.
I've just started doing this as well for some reason. Not sure why I didn't do it earlier.
I find a good example of modular css like this is for sprites. ie, class="sprite logo left" , .sprite set display, background-image/repeat etc, sets overflow, text indent. .logo sets height, width, and background-position. .left (or whatever) is for any non-generic styling that you might not want to use all the time when showing the logo.

For me:
class names = for css,
id = for javascript (where possible)
I did an entry for the 10k Javascript competition a couple of years ago, and without helper classes, I'd never have made it under. .s for drop shadow, .g for gradient, .r for rounded, etc. Since then, it's an approach I've been happy to use for larger scale projects: sometimes as generically, sometimes a little more controlled.
Love the sandwich example. Makes me hungry, but it's a great example and the image will now be stuck in my head forever.
Add a comment...