I work on a massive website that has many disparate pages. We have a default stylesheet that is shared across practically all pages. I find it useful to have CSS rulesets such as these:

.center { text-align: center; }
.red { color: red; }

This is commonly done, but in my opinion it is a very poor practice. It’s only a teeny tiny bit better than just putting all the styles inline. The only advantage you get is that you can choose a different shade of red.
It’s so antithetical to the idea of CSS that it would be a candidate for thedailywtf.com, if only it weren’t such a common practice.

Instead of

<div class="warning">Do not cross the streams!</div>

You have

<div class="warning red center">...</div>

and elsewhere:

<span class="red">...</span>

<div class="center">Some heading or caption or whatever</div>
<div class="warning bold black">A different kind of warning?</div>

What are you going to do when your client wants to change all the warnings to black text in a yellow filled box with a black border, floated right? A task that should take ten minutes instead takes ten hours.

Sure, it’s more work now to assign semantic class names to all your content, but doing so makes it very easy to adjust the look of the site in the future. The bigger the web site, the more important it is to do this properly. If you are familiar with word-processing applications, think about adjusting the subsection headings in a 50-chapter book where no paragraph styles were used.

If you want some “warnings” red, and other “warnings” not red, then you need two separate classes, e.g. “warning” and “serious-warning”.

I recommend Transcending CSS: The Fine Art of Web Design by Andy Clarke, Molly E. Holzschlag, Aaron Gustafson and Mark Boulton. It’s a beautiful book, and does a great job of explaining how and why to separate the semantic content from the presentation.

First of all this is a good question, I don’t think that is is hyper technical and it makes a lot of sense.

encouraged is a key word here.

What you are doing is very common practice, it is extremely hard to do this sort of styling without this technique using CSS. CSS is there to describe what we want the element to look like, it is our styling language and it really only hooks effectively to ids, class names and tag names (all other selectors are considerably slower last I checked). Out of these three classes make the most sense. This is because IDs are unique and tag names are even more descriptive of what an element is and not how it should be displayed.

I understand the W3C’s argument, in programming most of the time classes describe of what type and object is and how it behaves and not how it should be presented.

• One alternative is using a more robust templating language such as SASS and use mixins (see example on home page). This would let you give classes descriptive classes and share a ‘center’ mixin. I don’t like this though since it involves embedding another technology to your code. LESS is also such an alternative.
• Yes, you can inline the styles, you can also do so programmatically (use classes and have a script embed the styles on the back end). I really do not see the benefit of doing that though except of adhering more closely to the W3C’s recommendation.
• You can keep doing what you’re doing. Which works but does not adhere to the W3C’s encouragement.

When you inline styles you’re also going to have the following issues:

1. elements with IDs will have their style values overridden by the inline style. An ID selector takes precedence over a class selector but inline styling beats both. This is not a problem if your styles are all of the sorts of ‘center’ but it is worth keeping in mind. You’d be surprised how much broken code exists on the web that fails for that reason.
2. Even classes ‘center’ might have a different meaning in some scenarios, you might want to also set the additional properties and not just the text-align and still be center. With center and red it’s not that big of a problem though

Here is what I think you should do:

Try SASS or LESS, if these work for you they can end up saving you a lot of time. If that doesn’t work I would continue using classes as a form of the mixin pattern to share properties across elements.

I do agree that the name ‘class’ for something that describes how an object should be displayed and not how it actually is is confusing, classes double today both for the presentation logic in CSS and it’s code logic in JavaScript.

Good luck!

Using more semantical class-names really comes in handy if you are designing more than one style, for example a mobile version. They may share lots of code, but sometimes ‘center’ shouldn’t be centered anymore in the mobile version. Or something is put on a different background and therefor should use maroon rather than red. Restyling things like ‘center{ text-align: right;}’ is just confusing.

So I would encourage semantical meanings and style them. To avoid redundant coding of styles that keep recurring (for example ‘font-weight: bold; text-align: center; color: red;’ for several warnings and other red text Sass or Less could be very handy.

However, I would not spend ages renaming all your classes if you don’t have multiple styles and the layout isn’t subject to change. It is after all only for your own convenience (and the developers after you, if there are any.) Browsers do nothing with the semantical value, if anything use role-attributes.

I wouldn’t use inline styles too much, but they can be useful. For example when the styling comes from a tool and is generated. It’s just not productive to jump through hoops to rewrite the generated code to classes only to style them. (Especially when changing the settings of the tool will allow for easy change.)