Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The W3C spec on the class attribute says

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

Reference

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; }

However, these classes do not semantically describe content.

I'm sure you can understand that there are an enumerable number of cases where I need to center text or color it red, and each of these specific instances may have nothing to do with one another. For example, the class warning may be useful in one spot, but in another it may just be aside. I wouldn't necessarily want all warnings to be red either.

I realize that this is a hyper-technical question, but I do want the hyper-technical answer. Is there any correct way to reconcile having general style rules that express no semantics with the HTML spec? Is this a case for shudder inline styles?

share|improve this question

3 Answers 3

up vote 5 down vote accepted

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.

share|improve this answer
1  
Your answer assumes that I don't already do both (i.e. all warnings have the class warning even if they already have the class red as well) –  Explosion Pills Feb 1 '13 at 17:04
    
You also assume that all "warnings" would want to have the same style or change styles simultaneously which may also be untrue. Even if it is, why would I have to change the content? .warning should come after .red in the cascade –  Explosion Pills Feb 1 '13 at 17:11
    
@ExplosionPills: Then you have "warning red" elements which are not red. I'm sure that will be perfectly clear to the next guy. If you have two kinds of warnings, then you need two semantic classes, not a semantic class plus special presentation. –  kevin cline Feb 1 '13 at 19:57
    
@kevincline: If a document has textual content which refers to warnings as red, then it would make sense to have a class refer to them as such. Even if the document is being formatted for a monochrome printer and it's necessary to substitute thick gray text, a class "red" would refer to "the style which the text refers to as 'red' regardless of actual rendering". –  supercat Nov 10 at 23:00

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!

share|improve this answer
    
I meant "hyper-technical" in terms of being very strict in following the technical spec, not in terms of question specificity. Thank you for your answer! –  Explosion Pills Feb 1 '13 at 15:20
    
Re: SASS/LESS, that only allows for adherence on the back end, but since ordinary CSS/HTML is what's ultimately emitted it doesn't actually alter your markup's adherence. –  Explosion Pills Feb 1 '13 at 15:22
    
You can use SASS/LESS on the client side , there are instructions on how to do it (for LESS) here: lesscss.org/#usage –  Benjamin Gruenbaum Feb 1 '13 at 15:24
    
Yes, but what is ultimately emitted is still normal CSS! –  Explosion Pills Feb 1 '13 at 15:28
2  
You are right, but this way your objects can have semantic classes, your warning will no longer have the classes 'warning' and 'red' but only 'warning' which conditionally has the 'red' mixin. Like I said though, I think that what you're doing with css is perfectly acceptable. –  Benjamin Gruenbaum Feb 1 '13 at 15:33

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.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.