Grow your CSS skills. Land your dream job.

What do you do when your design pattern breaks down?

Published by Chris Coyier

Say you have a module. Every site has modules, right?

<div class="module">
</div>

Perfect! We did it!

But now, a New Circumstance™ comes along. This module isn't going to work exactly as is. It's pretty close, but in this New Circumstance™ the module is going to need some extra bottom margin.

How do you handle that? Let's explore some ways.

Body class affects it

Are all the modules on a particular page or area of your site like this? Perhaps you can add a class to that page (or area):

<body class="books-page">

   ...

   <div class="module">
   </div>
.module {
  /* normal style */
}
body.books-page .module {
  /* variation styles */
}

You don't really need to tag qualify the .books-page, but I often do because it's no big deal in this circumstance and reminds me what's going on.

Sass is useful in these circumstances because the nesting kinda ties the room together.

.module {
  /* normal style */
  aside.books &  {
    /* variation style */
  }
}

Totally new class

Perhaps the new style is different enough that you are going to call it something different.

<div class="solitary-module">
</div>
.module {
  /* normal style */
}
.solitary-module {
  /* alternate style */
}

If the style are pretty similar, you could:

.module, .solitary-module {
  /* normal style */
}
.solitary-module {
  /* variation styles */
}

Which is exactly what @extend does in Sass:

.module {
  /* normal style */
}
.solitary-module {
  @extend .module; /* could be a %placeholder selector */
  /* variation style */
}

Double up classes

Perhaps you create an additional class, but that class isn't meant to work on it's own, it's just a variation.

<div class="module module-books">
</div>
.module {
  /* normal styles */
}
.module.module-books {
  /* variation styles */
  /* you don't HAVE to double up the classes here in the CSS, but it enforces the connection (while increasing specificity) */
}

Data-attribute variations

I don't think this is particularly common, but I kinda dig it.

<div class="module" data-variation="books">
</div>

Attributes are like classes (same specificity) but can have values.

.module {
  /* normal styles */
}
.module[data-variation="books"] {
  /* variation styles */
}

Reads pretty well.

Inline styles

Is this variation rare? Perhaps just an inline style will work.

<div class="module" style="margin-bottom: 40px;">
</div>

Typically frowned upon (not reusable), but if it's a one-off thing, it does the job.

Shame.css

You can always deal with it later with shame.css!

<div class="module chris-did-this">
</div>
/* I will totally deal with this later I promise */
.chris-did-this {
  /* variation styles */
}

How do you do it?

Comments

  1. Data attributes are meant to carry data, so using it to style things feels weird.

    I’m personally for the “add extra class” (double up) for different variations idea. It just feels “right” and keeps the modular aspect.

    • Zama Khan Mohammed
      Permalink to comment#

      I agree with you that data attributes are meant for carrying data, but It can also be used for styles as we want to reduce the number of classes we add to the dom, and many a times a data attribute can be helpful to make the code more semantic.

      Anything that makes the code less, and cleaner should be preferred.

  2. Personally I use the “add extra class” or “body class effects it” variants. Their simple and keep you from cluttering up your style sheet. However if I find myself doing this more than a couple times I go back and recreate it to be more flexible.

  3. <div class="module module-books"></div>
    
  4. Permalink to comment#

    The nifty thing about data attributes is that you can completely skip adding the class and just leverage attributes.

    For example, this could be a default module:

    And this could be a fancy module:

    &lt;div data-module=&quot;fancy
    

    The CSS is pretty straightforward:

    [data-module] {
        ...default styles...
    }
    [data-module="fancy"] {
        ...extended styles...
    }
    

    You can also make your own custom module-specific “classes” by using the [~=] selector:

    [data-module~="typeA"] {
        ...styles for typeA...
    }
    [data-module~="typeB"] {
        ...styles for typeB...
    }
    
    • Permalink to comment#

      It appears that some of my code blocks weren’t quite right

      The default module is:

      <div data-module>

      and the fancy module is:

      <div data-module="fancy">
    • Vince C
      Permalink to comment#

      Hmm, I quite like this idea..

      The thing is, are these data attributes more semantic than classes, or are they less? Also, when do you choose which one to use?

  5. John
    Permalink to comment#

    I am personally a fan of the “Totally new class” method as the logic is similar to OOP principals, where the formatting of the class name would be .super-class--sub-class.

    .super-class,
    .super-class--sub-class {
        generic rules...
    }
    .super-class--sub-class {
        specific rules for just this sub-class...
    }
    

    This allows regular class names to use hyphens while the double hyphen signifies that the super class is being extended by a sub class, which is where rules can be added and rules inherited from the super class can be overridden.

    • wqeqwewq
      Permalink to comment#

      Bad idea. People will think that you are using BOM and get confused that you are not using it.

      Cheers.

    • Eric
      Permalink to comment#

      I have to agree that I don’t think it’s a great idea and doesn’t really imply OOP inheritance principles. Think of a Java class for instance. It’s been a while, but iirc its something like public Mustang extends Car{} (I’ve been in C# for years but many languages use something close to that syntax). What you’re implying is almost the reverse and without a preprocessor would be the complete opposite of inheritance since you’d have to maintain two CSS classes when the base class changes.

      That said, I’m a fan of the human readable double class style. With programming languages yes the base class comes last and in markup it comes first but its not a complicated concept to grasp and closer in line with what programmers are used to, and eventually we want to move into a world where we separate concerns where the people working on the styles don’t need to be the people writing HTML as well. The less complicated we make applying styles (class plus class plus class equals result) rather than looking through a style guide for the specific class for an emphasis button with a red background, for instance.

      Plus, you’d be creating a lot of barely used classes and increasing payload for very specific instances instead of promoting reusable components.

    • Eric
      Permalink to comment#

      Edit (am I missing something or can I not edit my original post from my tablet?)

      I see what you’re doing won’t really break inheritance rules, although it does complicate them by creating several variants end users need to dig through to get what they need over combing classes. It also creates a lot of overhead for little return. I do apologize for wrongly implying that you’d need to change base and sub classes using your model but still stand firm that the more specific sub modules become the more maintenance will be required by needing to add new classes for each instance instead of having a disposal of common classes to build modules upon. Forgive me, I’m on a tablet and its 2am. But I still maintain my stance ^_^

    • John
      Permalink to comment#

      Thanks for the feedback. Constructive criticism is always good, and I do admit this model doesn’t work well for all projects and I’ve many times needed to instead use the double class model.

      @wqeqwewq I’m not familiar with the term BOM and a google search revealed very little. If you’re referring to something like BEM I do see your point and it could be confusing, but is only an issue if working with a team or releasing something to the public web development community.

      @Eric Points well taken, however aside from the philosophy behind the naming and formatting of these two examples I see no technical difference: .baseclass--modifier and .superclass--subclass As for the order of the super class and sub class, you are correct. PHP, Java, and ActionScript (among others) all use the syntax structure of Subclass extends Superclass {}. I am well aware of this and format the css classes this way intentionally because, for me at least, it’s quicker and easier to tell what a class is doing and keeps things organized in the css file.

      .module,
      .module--full-width {
          rules for all modules...
          width: 20rem;
      }
      .module--full-width {
          width: 100%;
      }
      

      As for the issues that arise as modules become increasingly complex, thus necessitating an entirely new sub class, you do make a good point – more overhead for little return. One way to overcome this is to use a mixture of the double class model (as utility classes) with the super/sub class model.

      When working with a team or releasing to the public I certainly adhere to the style guide and formatting model already in place, but for my personal projects this model works well for me. That said, I appreciate your comments and will have to rethink if this model is best for me.

  6. Most of the time I “double up classes,” though I rarely adopt that level of specificity in my CSS if I can avoid it (the exception being states of a class, a la is-active). If I feel the new pattern is similar now, but has a high risk for splintering off in dramatic ways in the future, I’ll throw caution to the wind and duplicate stuff in a wholly separate pattern. But that happens less often.

    And I’m also not averse to adopting the ol shame.css technique now and again, especially when deadlines are looming. “Real artists ship” and all that.

  7. Guys, this is exactly why we have “Utility classes”.

    • Vince C
      Permalink to comment#

      To just add a margin, yeah. But utility/helper classes are not to extend other classes.

    • Yes, exactly. I should have been more specific that I meant that for exactly this example.

      For a few minor tweaks that might be a one off, I use utility classes. If I feel like I am adding to many and it is a style that will be used more than once, make it a component modifier or a new component.

      Each situation calls for different solutions. Knowing the right one to choose comes with experience and maintaining large projects for extended periods of time.

      Nicolas Gallagher gave a great talk at CSSconf AU about this and how to be careful about your abstractions.

    • Taylor Jones
      Permalink to comment#

      That was my exact first thought. Have some utility classes that have a standardized “spacing” amount for margin. Make it a variable in Sass/Less. I even use a half-spacing variable as well in the event the normal margin spacing variable is too large.

  8. William Lubelski
    Permalink to comment#

    I’ve used the double class plenty of times, but if you ever end up with more than a few variants, it would often get painful to manage, especially if you ever want to edit the base.

    Nowadays I might wrap the module in a div and style that div, but my favorite way to handle this is have:

    (using less)

    .module-styles(){
    margin: awesome;
    border: snazzy;

    }

    .module-foo{
    .module-styles();
    margin: ballin';
    }
    .module-bar{
    .module-styles();
    margin: stellar;
    }

    your rendered CSS has redundant styles, but if your app is performance sensitive to that in 2014 I have no idea what you’re doing. by doing a style override in the “semantic” class definitions, you don’t have to reason about class specificity, just style order, which I find much simpler.

  9. Permalink to comment#

    If you use BEM style (which I like to call GRM – group, role, modifier :)):

    .module,
    [class*=module__] {
      padding: 10px;
      display: inline-block;
      background-color: #ccc;
      &:before {
        content: 'module';
      }
    }
    
    .module__extraSpace {
      padding: 20px;
    }
    

    http://codepen.io/anon/pen/dqGyr

    • Ralfff
      Permalink to comment#

      I came across this not too long ago, this is how I do it:

      [class*=module] {
         padding: 10px;
        display: inline-block;
        background-color: #ccc;
      } 
      
         .module-pad20 {
               padding: 0 20px; 
         }
      

      Is there a reason for double-declaring it like this:

       
      /*why?*/
      .module,
      [class*=module__] {... 
      
      /*wouldn’t this be better?*/ 
      [class*=module] {... 
      

      Maybe a fallback for older browsers?

      (got this from 24ways btw. If anyone’s interested, here you go: http://24ways.org/2012/a-harder-working-class/)

    • Permalink to comment#

      @Ralfff, the reason for that is because if in the css which was loaded on the page (could be a 3rd party css too) you’ll happen to have something like .awesome-modules or .user-feedback-module then your styles ([class*=module]) will get applied and you’ll have to redefine them. Though if you’ll follow naming convention which BEM (again I call it GRM :)) is using (http://bem.info/method/definitions/, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/) where you divide css classes naming in 3 parts: .group--role__modifier, for example (just from top of my head :)): .button, .button__primary, .button__primary--alternative, .button--icon, .button--icon__arrowUp, it is quite unlikely that you’ll run in such a situation.

      I can guess that you might be confused – it is quite unlikely that I’ll run into a situation like that, and if it’ll happen, then I can adjust styles for that particular situation. That is very true, when you work on a project with 1-2 front end people. In my case I’m working on a project with ~30 developers and all of them could contribute to css, so it is very important for us to make have these conventions. But if I’ll leave the project and start working on my own, I’ll still be using GRM.

      @everything, sorry for confusion, I guess it is common to use -- for modifier and __ for element separators, and in the examples I reversed them :)

    • Permalink to comment#

      And the reason for double-declaring is that I want the styles to apply only to elements which match .module + elements where that module has a modifier [class*=module__] will be applied to .module__books, .module__whatever, ....

    • Ralfff
      Permalink to comment#

      Ah, alright, makes sense. Seems like I’ve got some “rewriting my framework” to do.

      I’m working mostly small to medium projects (2 devs) and am familiar with the BEM Method. My CSS is loosely based on that, but never got around using__ and--. Just the single dash works for me.

      Thanks Sergey.

  10. Why not use an ID instead of a class for the body style?

    • ewvfwe
      Permalink to comment#

      IDs are evil. Nuff said.

    • Ralfff
      Permalink to comment#

      IDs are too specific and hard(er) to overwrite. Classes do the exact same thing.
      I totally dropped IDs in my CSS.
      I still use them as Anchor in HTML and for jQuery.
      If I have to use them for Styling (e.g. styling WP-Plugins or someone else’s code) I target them with the attribute-selector [id="name"], so they have same specificity as a class.

      “Nuff Said” is evil.

    • John
      Permalink to comment#

      @Ralfff Clever method for avoiding a specificity nightmare with WP-Plugins by using the attribute-selector. Thanks for sharing!

    • Ralfff
      Permalink to comment#

      Ha, no problem. But to be fair, I’m not that clever, Harry Roberts is:

      http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/

  11. Permalink to comment#

    Additional class! Been used to doing that for some time now.

    …and lol @ shame.css haha

  12. Robert Smith
    Permalink to comment#

    I would double up on classes, In Chris’s example the module is identical apart from the fact it has some extra margin bottom. It’s really an extension of the module object so in my opinion this is the way to go.

    ...
    
    
    • Robert Smith
      Permalink to comment#

      ** … **

    • Robert Smith
      Permalink to comment#

      Third time lucky… I go for the class of alpha to keep the classname from being tied to the content, we never know if it might get reused for something entirely different in the future.

      <div class="module module-alpha"> ... </div>
      
  13. Double-up those classes, with a few naming conventions. Last year’s Smashing Mag article on the London Times’ site redesign prompted me to detail my approach and naming conventions.

  14. Mostly with an extending class the BEM style

    Sometimes over the body or HTML element class, e.g. when using WordPress, the body classes are inserted automatically for a particular page and when I’m just too lazy to add additional parameters to my server-side code.

    When adding to the body or HTML Element, I create a mixin to make changes easier and less errors while using.

    @mixin on-books-page(){
      .books-page {
        @content;
      } 
    }
    
    @include on-books-page(){
      /* style changes for books-page */
    }
    
  15. It depends on the purpose of module. If the module is something really self-contained that could be used on many pages and in many contexts, then it probably shouldn’t include any layout-type rules at all. Layout rules would be things like float, width, margin.

    I would nest those portable modules inside of more generic layout modules which would be used for inter-module positioning. The HTML looks uglier and can border on div-itis, but the CSS is pretty clean and portable.

    • Ivan
      Permalink to comment#

      Congrats on being the first person making sense :) I’ll just add the example:

      <div class="layout">
          <div class="module"></div>
      </div>
      
      <div class="otherLayout">
          <div class="module"></div>
      </div>
      
  16. Wolfgang Kluge
    Permalink to comment#

    Currently I try to use double up classes without repeating parts of the name.. Something like

    .specific.module {}
    .next.module {}
    

    Thus I have to be more specific in the first place.
    It’s far away from being perfect, but I like the readability…

  17. Toby
    Permalink to comment#

    I’d double up the classes but make sure those classes were modular. I’d use OOCSS to do this, adding a class of .mbm (margin-bottom: $medium)

  18. Vito
    Permalink to comment#

    I’m thinking about this many time. Now I use the BEM “way” using class=”module–solitary” and then in the .less file:

    .module--solitary {
        .module(); // in this way I catch the "normal css rules" for module
        background-color: differentcolor;
    }
    

    Vito

  19. philtune
    Permalink to comment#

    Most commonly use body.contact .aside_module. But I’m really not above doing inline styles, or even “ blocks, as there’s usually not enough bytes to weigh down my page and definitely not enough to justify an additional request. I always like making my stylesheets as universal as possible, so inline styles also lets me keep my stylesheets clean.

    I try to use [data-*] for Javascript only.

    I’ma read that shame.css article now. Sounds like that might be a good way to go.

  20. Permalink to comment#

    I go with an additional class and the @extend in Sass. Feels right, simple and easy to update/remove.

  21. Permalink to comment#

    I usually try to double up on classes, unless it’s a one off in which case I’ll either do a quick inline style or something a little more shameful like you demonstrated above. I come across a lot of cases in my work where margins need adjusted though so I’ve got some generic margin styles too. I usually have something like the following available:

    Where m stands for “margin”, “p” for “padding”, “t” for “top, etc
    .mt10 { margin-top:10px !important; } .m10 { margin:10px !important; }

    The !important is only there because I work on a lot of other peoples code where the inheritance isn’t usually known off the top of my head, so these quick fix classes can save a lot of time on spacing issues.

  22. Permalink to comment#

    I tend to double up classes .module.module-books. But recently my mark-up has starting looking a bit messy, I seem to need about 7 classes sometimes, which I’m not too into. This is mainly on .grid elements though. Suppose the module could be a .grid too though…

  23. Vince C
    Permalink to comment#

    Most of the time I use the “double up” classes. If it just needs 1 commonly used property (like a margin-bottom), I typically just create a helper class .md (for margin down) for it and add it to the html, if it’s an actual variation, I go for .module-variation.

    I sometimes use body classes, but mostly just for javascript..

  24. I usually use a modifier class. Never used inline style!

  25. It depends, if I only need to add some margin bottom, I usually have a number of helper classes like .margin-bottom, .margin-bottom2x, .margin-top, etc.

    Then I just add the modifier class.

  26. Permalink to comment#

    Add an extra class! In the past I might have done a module extension, but lately I’ve been loving the Inuit style helpers. So instead of adding a .module-books I’ve been adding stuff like .push--bottom (I’ve been using Inuit 5; https://github.com/csswizardry/inuit.css/blob/master/generic/_helper.scss)

    The key here to this New Circumstance™ is that the extra bottom margin will probably be a design pattern that happens again. This kind of abstraction while almost too simple has been really helpful for me.

  27. Permalink to comment#

    I vote to use a new style! And if you’re using SASS, import the base style’s properties.

    The double class is nice for organization, but I’m sticking to my first line.

  28. Permalink to comment#

    I’d do something like this. If its just a change of color, padding etc..

    <div class="module has-margin"> ... </div>
    
    .module {
    ...
    }
    .has-margin {
    ...
    }
    
  29. I try to use the block element modifier methodology. In this instance, I’d probably have the base .module class and then for the additional margin I would do something like .module--dbl (or something similar, depending on how much more margin and whether or not it is margin all around or just on a specific side (top, left, bottom, right).

  30. You could always name the module semantically:

    Then in scss:

    .user-biography { @extend %module; padding-bottom: $bigPadding; }

Leave a Comment

Posting Code

  • Use Markdown, and it will escape the code for you, like `<div class="cool">`.
  • Use triple-backticks for blocks of code.
    ``` 
    <div>
      <h1>multi-line block of code</h1>
      <span>be cool yo.</span>
    </div>
    ```
  • Otherwise, escape your code, like <code>&lt;div class="cool"&gt;</code>. Markdown is just easier though.

Current ye@r *

*May or may not contain any actual "CSS" or "Tricks".