Is there a standard method for naming classes? [cl

Question

For example:

class="profile profile-image profile-image-large"

OR

class="profile profile-image profile-image-small"

Is there something wrong with these names or dashes?

Answer 1

A good rule of thumb when naming classes is to describe the purpose of the element's content.

PREFERRED

<div class="copyright"></div>

          OR

<div class="social-media-buttons"></div>

In contrast, for reasons described below, being overly precise should be avoided.

LESS BENEFICIAL

<div class="column-1"></div>

          OR

<div class="right-bottom"></div>

Here are some guidelines from the W3C:

Use class with semantics in mind.

Often people use class names like bluetext, or redborder. A much better way to name your classes is with the role a certain HTML element of that class has.

Good names don't change

Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Good names
warning, important, downloadableImage and submenu are all good names. They describe what a certain element represents, and they are not likely to change. A warning will always remain a warning, no matter how much the look of the page changes.

Bad names
border4px, lighttext and prettybackground are examples of bad names. You might fatten that border to a whopping 5 pixels, or the background may look pretty old after a while, and not pretty at all. An advantage of using CSS is that you won't have to change much in order to change the looks of your website. If you have to change all light text into dark text, and thus change all classes lighttext to darktext in all your HTML pages, you're likely to miss a few.

So, to answer the question:

Is there something wrong with this?
class="profile profile-image profile-image-large"
class="profile profile-image profile-image-small"

Well, do these class names represent "the role [the] HTML element of that class has"?

It's mixed. profile and profile-image are clear roles. But large and small simply represent how the image should look, which, as the W3C points out, can change. And if the size changes then the class name may have to change, as well.

Which leads me to this: The important issue isn't really the prefixing, suffixing or hyphenation of class names. What really matters is the quality of the name itself.

Maybe this would align with the W3C guidelines and offer greater benefits in terms of reusability, flexibility, and maintenance.

class="profile profile-image profile-image-main" 
class="profile profile-image profile-image-thumbnail" 

Answer 2

To be perfectly honest, this comes down to individual developers and their own feelings. There are two equally good ways of structuring CSS classes, just like you suggested:

.profile.image.large{
    width: 300px;
}

/* Or: */
.profile-image-large{
    width:300px;
}

They achieve the same thing, but when you start thinking broadly, you see just how wide the gap between these styles becomes.

Separating classes makes them re-usable: The DRY convention is to never repeat yourself. By separating the large or image classes, we can reuse the same class:

.blue{
    border: 3px solid blue; /* All .blue's will have a blue border */
}

.profile.blue{
    border-style: dashed; /* Inherits from the previous blue and replaces the solid with a dash. */
}

In the second approach - using - separators, the code would be:

.blue{
    border: 3px solid blue; /* All .blue's will have a blue border */
}

.profile-blue{
    border: 3px dashed blue; /* We had to redefine the entire style */
}

On a simple example like a border, this doesn't seem to matter. But take into account a much larger CSS chunk that you may want to re-use dozens of times throughout your code. You'll be repeating yourself a lot.

Logically grouping styles is still a good thing: I'm not saying that -classes are a bad thing - they help define a namespace for your code, so in the sense of maintaining modular code, prefixing your styles with an identifier will help prevent conflicts, especially if you're developing code inside a web agency that will be re-used, or if you're building a plugin (in which case, style prefixing is absolutely needed).

Developing in a compiled language like SCSS (my preferred environment) changes how you think too. In SASS/SCSS we can easily do this:

.profile{
    display: block;

    &-image{
        border: 1px solid blue;
    }
}

And that evaluates to the same as profile profile-image on the element. Alternatively SASS also supports:

.profile{
    display: block;

    &.image{
        border: 1px solid blue;
    }
}

Which evaluates to profile image on an element. Very similar - but both styles are restricted to their parent element .profile and can't be used globally. The styles are protected, whereas in my first 'natural' CSS example, the blue class could freely be added and incorporated by any element in the HTML page.

Edit: You could still use a global .image style in your SASS code, and then override individual examples, but personally, I feel this violates the DRY principle and I try to avoid doing it where possible.

So what's the TL;DR?

In my opinion, there's no "right answer". From a conventions standpoint, it's worth noting that frameworks like Twitter-Boostrap use a hybrid of the two styles - global classes that can be applied everywhere, mixed with prefixed classes that protect their children's styles.

The most important thing for any programmer is that your code is clearly readable and defined, and that you use as little code as possible to achieve your result - no matter what method you use.