Should css class names like 'floatleft' that directly describe the attached style be avoided?

Question

Lots of websites use class names like floatleft, clearfloat, alignright, small, center etc that describe the

Answer 1

It depends, sometimes it makes sense just to add a class to let an element float. The problem with the semantic approach is that you will end up ball of mud of css classes. Sure, names like redLink or blackHeader have to be banned but sometimes you will need little helpers like "clear" or "floatLeft".

Read this article of Nicole Sullivan who explain this in deep.

Answer 2

There are two things that I feel get entirely left out of these discussions all too often. The first is WHY you would want to be all semantic or all not. The keywords are Branding and Skinning. Presentational class names may be justifiable if you work on some internal, departmental websites where branding and skinning will never in a million years get funding. On the other hand, customer facing sites, such as car manufacturers and department stores live in a world where every single new product that gets launched results in an entirely new skin for the website. New colors, new layout, new background images and all of this lead by designers who should be able to make the change purely in css so there's no chance they can break any working php (or what-have-you). There are also branded sites, where you have multiple skins, potentially running on the same site simultaneously. On sites with that requirement, you can't have visual changes impact html or you end up breaking every other brand just to update one of them. In these situations, semantic class names are a necessity.

The second thing that often gets left out is how to combat the problem of repeating groups of properties created by semantic class names, as in:

.content-nav {
    float: left;
    margin-right: 10px;
    background-color: #ccc;
}

.content-nav .user-photo {
    float: left;
    margin-right: 10px;
    border: solid 1px #000;
}

.content-nav .user-display-name {
    float: left;
    margin-right: 10px;
    text-decoration: underline;
}

People often point this out as a drawback of semantic names, and I think that that's a valid point. On the other hand I would like to point out that there are tools that can help you keep semantic css DRY, such as LESS and SASS. I did see one other commenter mention this above, but I just thought that this point was worth highlighting.

Answer 3

I think this is where old meets new in web technologies. From times past, it has been difficult to unobtrusively render an outstanding web experience. These class names mostly came in handy when websites were changing webmasters to aid them in understanding the code. It served its cause well but with the new technologies of this day and age, I think this is slowly dying out - infact, it should be dead.

The question we should ask is, "Do we need to create a new class for every new innovative design that could pass as a template?". I do not think so. The markup on a site should do what it is meant for - markup. The class names used in the markup should be descriptive of the content and not its looks. The stylesheets - on the other hand - should be able to select elements on a document based on the information in the markup, and style them.

I want to relate this to the Rails association naming convention. Consider this...

class Post < ActiveRecord::Base
    has_one  :personifyable
    has_many :personifications, :through => :personifyable
    has_many :taggables
    has_many :tags, :through => taggables
    belongs_to :destroyers
end

Obviously, this is not a real model; it is something I am using to drive a point. Consider the case of a deeply nested dependency. These names will grow ridiculous - if they aren't already (i.e. in CSS, <div class='mediumwidth floatright centeredtext graytheme master'></div> or something of the like)

Now consider the case where you have different principles. Different developers and designers may - if not 'most definitely will' - have different reasons for using a specific naming convention. How would this affect refactoring time. I will leave that to your imagination. Also, if your business partner notices a new trend with sites themes that attracts traffic - more technically, assume this business partner has performed some experimental A/B testing and come up with some specs - you don't want to change the contents of the whole stack (ie HTML and CSS and possibly JS pages) to implement this new style.

In conclusion, keep styling hints out of your markup. Unobtrusively interact with the document to style and manipulate it. Sass gives you a fine way of styling a site while having your CSS mock your markup. jQuery is another awesome UJS library. HTML5 gives you methods too that make the markup more flexible and yields more information to CSS and JS.

Answer 4

Class names and ids that describe the function is better than using names that describe the styling of the element.

I usually end up not doing it religiously though, because it is in my opinion more convenient to i.e. clear floating elements by using the famous clearfix hack rather than adding clear:both all over the stylesheets.

But I think that LESS and SASS creates interesting opportunities to get the best out of both worlds, because you can have mixins and functions that describes some style and still have semantic correct names by just including whatever 'style' you want.

Instead of having this HTML and CSS

<div class="navigation roundedcorners">...</div>
.roundedcorners {
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
  border-radius: 5px;
}

you could use SASS to create this mixin:

=rounded-corners
  -moz-border-radius: 5px
  -webkit-border-radius: 5px
  border-radius: 5px

and include it into your .navigation class like this:

.navigation
  +rounded-corners-5px

which would reduce your HTML to this:

<div class="navigation">...</div>

and therefore still get the advantage of having semantic correct names while having a convenient way to share styles between different elements.

Answer 5

If the question is only one of naming, then for one specific class...

class="floatleft"

or

class="myClass"

or

class="gibberish"

....changes absolutely nothing. They are only different class names. The programming functions the same.

Either your content & presentation is separated, or it isn't... totally regardless of how you created the names.

Answer 6

Style classes should be semantic. This is a great article on semantic web page design (well, I found it really helpful anyway).

EDIT: I just read another article that makes some good points for using things like display: inline-block, display: table etc. instead of floats. That should help avoid those pesky floatleft and clearfix classes. Making them semantic is always up to you though.