0

I couldn't come up with a simple title that explains my problem, but I'll try to be clear.

Is this a good convention:

<div class="margin10 padding20 font28 display-block">Something...</div>
<div class="margin20 paddin30 font12 display-inline-block">Something...</div>

//CSS
.margin10{
    margin:10px;
}

.margin20{
    margin:20px;
}

.padding20{
    padding:20;
}

.padding30{
    padding:30;
}

.font28{
    font-size:28px;
}

.font12{
    font-size:12px;
}

.display-block{
    display:block;
}

.display-inline-block{
    display:block;
}

or

<div class="something-wrapper">Something...</div>
<div class="something-container">Something...</div>

//CSS
.something-wrapper{
   margin:10px;
   padding:20px;
   font:28px;
   display:block;
}
.something-container{
   margin:20px;
   padding:30px;
   font:12px;
   display:inline-block;
}

Basically the advantage of the first over the second is that I create lot of css classes following grid systems, conventions and patterns and can use them again and again in css. REUSABLE In second type I create individual css styles for individual elements where one might be usable in another but cannot be used due to naming convention.

Can someone help me on what is the best practice/industry standard here?

5
  • Probably off topic here. But, your second example is better because the classes explain the content (semantic) whereas the first describes the particular style. It's not true that the second is not reusable. You might want to look up OOCSS, if you want a systematic method. For example, you can create a class for action-button and then create child classes action-button-important, action-button-delete or action-button-save (for example) to tweak individual classes.
    – Brendon
    Aug 30, 2013 at 16:28
  • 1
    for me this is a grey area for UX, yes, it is a code related question, but I think this sort of topic is also very relevant to the user experience of the next developer to use your code. As with most UX questions the goal is improve the experience a human being has using a tool, and as a developer is a human being and a code base is a tool I feel that there is some place here for such questions
    – Toni Leigh
    Aug 30, 2013 at 16:30
  • 3
    This question should be migrated to stackoverflow, you'll get much better answers there. It is about implementation and requires expertise in CSS rather than in UX.
    – Izhaki
    Aug 30, 2013 at 16:57
  • Might be better to migrate to codereview.stackexchange.com Aug 30, 2013 at 17:18
  • Really sorry if this is a wrong post at this forum, request admins, please do the needful migrations if possible.
    – Wesley
    Aug 31, 2013 at 4:37

3 Answers 3

3

This isn't a UX question. But...

These are simply two different ways to go about it.

Contrary to the opinion shared by the other two answers, I say the 1st example is a perfectly valid way to go about it and is sometimes a much better way.

The term for it is Object Oriented CSS or OOCSS. The concept is to split your CSS styles into smaller 'bits' that can be mixed up and re-arranged and used on a per-element basis as needed.

The benefits:

  • for large sites with large teams of FEDs with a long site life-cycle, this method can produce a much smaller and more maintanable set of .css files
  • tend to mirror the model a lot of the CSS grid systems use
  • can make continued maintenance of the site a lot easier for 'new eyes' that may come to the project mid-stream.

The con:

  • you have a lot more class names in your HTML. However, that can be a pro in that it can make it a lot easier for your developers to modify the UI if they aren't CSS experts (I've found OOCSS models to be a good way to simplify the communications between the front end presentation layer folks and the back end developers that are spitting out the HTML).

I'd say your example isn't perfect, though...I'd suggest that you 'genericize' the class names a bit more (instead of padding20 and padding 30, I'd suggest using an arbitrary unit: padding-2, padding-3). If you get too literal with your class names, you run into a problem if you need to tweak things a bit.

For example, if you have a particular type of font styling (say, red and 20px) instead of doing this:

<p class="color-red size-20px">

try this:

<p class="color-tertiary size-large">

That way, down the road, if they need to tweak the large type from 20px to 22px and the tertiary text color from red to mauve, the class names don't contradict any of that.

So that addresses the first option.

When should you NOT use the first option? I'd suggest not using the first option when you have a small FED team and the site isn't huge and going to live on and on for years with constant updates. The latter is the more 'traditional' model and can make for a quicker dev time as you don't need to build the puzzle pieces of the OOCSS model first.

4
  • +1 but, while I'm all for OOCSS, I prefer to keep the class names more semantic. e.g. rather than "size-large" you could use "important" or "lead-text", depending on the reason.
    – Brendon
    Aug 30, 2013 at 21:06
  • 1
    @Brendon I'd argue "important" should perhaps be handled by actual markup (<em>) but, of course, it all depends on the particular need of the particular situation. I don't disagree with something like 'lead-text'. If it makes sense, definitely use it. That said, I've also found that being overly semantic with OOCSS can, over time (such as updates every 2 weeks for a year and a half) lead to extremely bloated CSS as the HTML begins to drive away from the original semantic class names through subsequent updates. Note that this is mainly a problem in large Agile teams where HTML may change
    – DA01
    Aug 30, 2013 at 21:40
  • drastically from iteration to iteration. Ideally, the CSS would keep pace but that can be a daunting task too. In my personal experience, I try to make OOCSS a set of generic building blocks that the developers can then pick-and-choose from to match the design specs. The idea is that they shouldn't be writing CSS at all (as the more people touching the CSS, the more accidental redundancy begins to appear). It's akin to how most CSS grid systems work. There is nothing semantic about the class names.
    – DA01
    Aug 30, 2013 at 21:41
  • This is the right answer. Because CSS only provides a single layer of abstraction - the class - classes should manage low level visual abstractions (like '.brand-color' and 'size-large') whilst higher-level abstractions are managed by the templating engine (eg sidemenu.jsp, tabbed-content.php). Aug 31, 2013 at 0:51
1

Your first example of using class names that are descriptive of their styles is a bad practice. Ideally you want to code the HTML in such a way that it can be restyled simply by plugging in new style sheets and without modifying the HTML. This ideal is not often achieved but using class names that describe their style tends to the exact opposite of this ideal, it effectively expresses specific styles within the HTML.

The practical problems with this are obvious if you had code like:

<div class="display-inline-block">

and in changing the layout to be responsive needed that div to be display:block to layout vertically. You'd have to go in and modify the HTML, possibly in many places. The above code basically handcuffs you. Keeping class names semantic like:

<div class="menu-item">

helps decouple the HTML from the style and gives you flexibility going forward.

I won't say which is the "best" convention for naming classes because there are a number of methods that work, but I will say naming classes after their styles is definitely bad, and in general you want to keep the HTML uncoupled from specific styles.

13
  • I wouldn't say it's a bad practice at all. It's just a different practice.
    – DA01
    Aug 30, 2013 at 17:17
  • 1
    @DA01 - For anything but the simplest of projects it's definitely bad practice to bind specific styles in the HTML to that degree.
    – obelia
    Aug 30, 2013 at 17:43
  • 1
    It's a common practice called OOCSS. While not everyone may agree with it, many do find it very useful on large projects where ongoing maintenance is a goal. I do agree that the particular class names are a tad too literal, but the idea of many--but simpler--classes is useful at times.
    – DA01
    Aug 30, 2013 at 18:05
  • I agree with OOCSS but it doesn't promote naming classes with presentation styles. Look through Nicole's code and you'll never see anything like class="size-large". There's the necessary evil of using grid references in class names when using grids, but beyond that OOCSS is as semantic as any modern methodology. stubbornella.org/content/2010/06/12/…
    – obelia
    Aug 30, 2013 at 19:17
  • I think it's debatable as to whether or not 'size-large' fits the OOCSS model. OOCSS does require a layer of disconnect beyond the typical semantic CSS names that refer to specific content. I do agree, however, with the example she gave "giantBlueHeading" not being a good idea.
    – DA01
    Aug 30, 2013 at 19:25
1

You can argue that the first example is not even CSS - if this is what you do you may just as well include the element style under the style tag.

The point of CSS classes is to allow the same style to be applied to more than one element, by that allowing easy and central way to apply visual changes.

If there's no common denumerator between the style of two elements, but you still wish to separate content from the view, you should simply use id tags (not classes) and give each element its specific CSS via the id selector. So your second option is nearly there - but using ids will be more logical.

1
  • Well, it is css. :) Just not the traditional model. It's closer to an Object Oriented CSS model which does have it's uses.
    – DA01
    Aug 30, 2013 at 17:17

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