Is this approach good or bad?

I need to create a bunch of boxes on my client’s website that contain different bits of info from facts to stats to adverts.

In the past I would just create one humongous style for each box like this…

<div id="boxSaveMoney">
  We save you $$$

    margin: 0 0 20px 0;
    padding: 15px 15px 15px 15px;
    border: 1px solid #3BAA00;
    -moz-border-radius: 6px;
    -webkit-border-radius: 6px;
    border-radius: 6px;
    background-color: #3BAA00;
    line-height: normal;
    color: #FFF;
    font-weight: bold;
    font-family: Tahoma, Arial,sans-serif;
    text-align: center;

For one box this might work, but if you have 30 boxes, it creates a mess and probably explains why my CSS is such a disaster!!

So this weekend - for whatever reason - I came up with this approach…

<div class="boxInfo bckgrd-green border-green font-tahoma color-white">
    <div class='size-0150'>We save you</div>
    <div class='size-0500'>$$$</div>

    margin: 0 0 20px 0;
    padding: 15px 15px 15px 15px;
    -moz-border-radius: 6px;
    -webkit-border-radius: 6px;
    border-radius: 6px;
    line-height: normal;
    font-weight: bold;
    text-align: center;

    background-color: #008000;

    border: 1px solid #008000;

    font-size: 1.5em;

    font-size: 5em;

    color: #FFF;

    font-family: Tahoma, Arial,sans-serif;

What do you think?

It some ways it looks messier because the style reference is much longer. However, it helps me to not create all of these similar styles that are one-offs.

I am all about coding efficiencies and could use some advice from a design guru!! :blush:

That approach is good, breaking your CSS styles into different types allows you to mix and match you box styles.

Since that’s text, I’d say span’s are more appropriate. They are already inline elements.

I was asking more about how I created a mix-n-match style approach.

But to your comment, I thought of < span > but since I believe it is inline and I needed inline-block or block I chose < div >

If you’re talking about

class=“boxInfo bckgrd-green border-green font-tahoma color-white”

Then yes. That’s actually the way I prefer to do things. It’s one of the principles of OOCSS and one of the key factors of Semantic UI.

Having 1 per class probably isn’t good for production, but I do this for prototyping. I’d break it down to be a little less verbose for production, except for the most common properties.

1 Like

If you look around the forums, I think you might see it mentioned once or twice that you should never choose elements based on appearance…

Use span and set display: block

<div class="boxInfo bckgrd-green border-green font-tahoma color-white">
    <p class='size-0150'>We save you <span class='size-0500'>$$$</span></p>

There is another approach to get the same result. In the css, define all the things common to all boxes in one go, by separating the classes by commas. Then define the classes individually with the things that are unique to them. For example

.redbox, .bluebox, .greenbox {
    width: 30%;
    border: solid 4px ;
    padding: 1em;
    color: #fff;
    text-align: center;
.redbox { 
     background: #d00;
     border: #fc0;
.bluebox { 
     background: #00f;
     border: #0cf;
.greenbox { 
     background: #0d0;
     border: #0fc;

Personally I prefer this, keeping all the long stuff in the css. I don’t want applying a class to an element to be like writing an epic every time, get it over with in the css once only.

1 Like

That’s good to hear.

You mean one attribute per class?

Verbose as in one attribute per class or as in my class names are too long?

Hey, that’s pretty cool. Thanks for a new way to mark up my text! :slight_smile:

1 Like

I guess it depends on the situation.

For these boxes, I was thinking they could be in an infinite number of styles and combinations, so I decided to break things out in granular enough fashion that I wasn’t creating 100 classes that could be re-used.

If I was just going to have a red, green, and blue box, then your approach makes sense.

Yes, 1 attribute per class.

@SamA74’s suggestion is perfect.

Try this:

<!doctype html>
<html xmlns="">
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1" />
  <title> Mikey_w </title>
<style type="text/css">
  body {font-family: Tahoma, Arial, sans-serif;}
  .bg0 {background-color:red;}
  .bg1 {background-color:green;}
  .bg2 {background-color:blue;}
  .bg3 {background-color:yellow;}
  .bg4 {background-color:cyan;}

  .fg0 {background-color:blue;}
  .fg1 {background-color:green;}
  .fg2 {background-color:red;}
  .fg3 {background-color:cyan;}
  .fg4 {background-color:yellow;}

  .fll {float:left;}
  .mga {margin:1em auto;} .mgr {margin:1em;}
  .p42 {padding:0.88em;}
  .rad {border-radius: 0.88em;}
  .tac {text-align:center;} .tal {text-align:left;} .tar {text-align:right;}
  .w42 {width:42%; max-width:22em;} .w88 {width:88%;}
  <div class="rad tac w88 mga">
      for($i2=0; $i2<888; $i2++) {
        $bg = 'bg' .mt_rand(0,4);
        $fg = 'fg' .mt_rand(0,4);
        echo '<div class="rad fll wdt p42 tac mgr  ' .$bg  .'">';
          echo $i2;
          echo '<p class="rad mgr ' .$fg .'">';
            echo 'class="' .$bg .' ' .$fg .'"';
          echo '</p>';
        echo '</div>';

I’m assuming your class names in your example are just that - examples - and you don’t actually intend calling things “bckgrd-green” or “font-tahoma”, right? Because if the client suddenly decides they want a pink background with Arial, you either have to change all your classes on every page of your HTML (thus undoing one of the great benefits of CSS) or live with the confusing fact that class="bckgrd-green font-tahoma" means you have a pink background with Arial.

If I kept things as in my OP, how much of an impact would that have on production?

And how would that approach compare to what I have been doing for years which is to create a brand new id/class for each new thing I create with no thought to reusing things.

Certainly the approach in my OP is an improvement over my past, no?

Looks like my approach was wrong (or not)…

First, I am a programmer by design, and I always make code (e.g. PHP) as verbose as possible because I hate sticking people with crytic abbreviations that don’t even mean anything to me a month down the road! (God bless you @John_Betong!)

Second, to your example, if a client wanted pink Arial, I guess I would just go back and change the style for the box to include those new classes.

I think it is important to keep the context of my info boxes here. Yes, if I had a style called .yellow-highlight and the client wanted all important text marked in blue, that would be confusing.

But that isn’t what I am doing here. Instead I created a generic box style - which is consistent with @mawburn and then I created a “library” of independent styles separated out in a granular enough fashion that I can indeed change the font, font-color, cont-size, etc and not have to rename the entire “God class”.

If I use one of these custom boxes in 100 places in my HTML, then both @SamA74 and my approach would suffer. I would have to chase down all 100 instances in my HTML and change both font-Tahoma ==> font-Arial and color-blue ==> color-pink. But then Sam would have to deal with a class called .greenBox that is now pink!! :wink:

But that means you have to edit your HTML every time you change styles. If that style is applied to - say - a heading, you may have to change it on every single page. That’s really not a sensible way of working.

That’s just a simplified example example, the concept is to group all the thing that make the classes similar, you did say “similar styles”, and then define what makes them unique.

If that’s the case, you may as well use in-line css and define the styling on a per element basis, which you are effectively doing by adding all that stuff in the element’s tag.

Yes, that appears to be a flaw in my approach.

But sadly, Sam’s approach suffers from the same flaw…

I don’t disagree with you, but see my last comment…

Unfortunately there is no “silver bullet” that I see. It is all about trade-offs.

You just change the css, that’s all. That’s the whole idea of external css files. If you are mixing and matching your styling on various elements like that, you should maybe be using in-line css to define the differences, you can still have a css file with global stuff in it too.