How many commas are too many commas in CSS

Similar post on this question: Using extend for clearfix

Say I was to make a handful of classes that I could extend and reuse throughout a project:

For example a class could be:

 //common boilerplate for most of my parent divs
 .scaffold
  {
    position: relative;
    -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
    height: 100%;
    width: 100%;
    margin: 0;
    padding: 0;
  }

//or a typical clearfix

.group:after {
  content: "";
  display: table;
  clear: both;
}

Say I had a dozen of these classes with various purposes and/or differences within the attributes. At what point does extending the class become hurtful towards performance vs helpful? For example - if this class had say 50 commas of various classes

Example of written one of the SCSS classes

   .site-header
      {
        @extend .group;
        @extend .scaffold;
        background: papayawhip;
        border-bottom: 1px #ccc solid;
      }

Example compiled clearfix could beCSS

.group:after, .site-header, .route-nav, .main-article, .article-header, .side-bar, .site-footer 
 //this could go on for a while
{ 
  content: "";
  display: table;
  clear: both;
}

Example HTML

<!DOCTYPE html>
<html lang="en">

<body>
    <header class="site-header">
    <nav class="route-nav">

    <nav>
    </header>
    <article class="main-article">
        <header class="article-header"></header>
    </article>
    <aside class="side-bar">
    </aside>
    <footer class="site-footer">
    </footer>
</body>
</html>

I feel like this could be one of the DRY—est methods to writing css. I feel like this approach could become very efficient and successful after writing just a few sections of a page. Moreover, majority of these classes could be refined and used through many project. I really want to experiment with it but I fear it could cause some performance issues in the long run, esp when classes start using pseudo-classes like :after :before.

Would there be a performance hit vs just adding the classes or writing a mixin? Does anyone have any statistics to backup the best route?

Solution

I like the idea of making scss placeholders and re-using them by @extend. This is known as the "OOSCSS" approach by some, you can find more about it if you google that. It helps writing DRY code and promotes reuse and consistency. I think you're on the right track with that idea generally, but specifically your scaffold class seems like it could be better:

 .scaffold
  {
    position: relative;
    -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
    height: 100%;
    width: 100%;
    margin: 0;
    padding: 0;
  }

Margin, padding could be set to 0 globally with a CSS reset approach, and so no need to set them each time. Box-sizing could be set with * selector, as I'm not sure you'd want to mix different box models on the same page. Making every element position relative may cause problems, I'm not sure I'd do that unless there's a good reason too. 100% width is the default anyway for block-level elements, and won't do anything for inline ones. And 100% height is rarely a satisfactory solution in my experience.

So I don't really think there's a need for that class at all. That's just an example though, the general point is if you're careful about structuring your HTML and CSS then you can get a lot of reuse from @extend without having many, many lines of commas in the generated CSS. I've found @extend'ed classes work best if they're small and specific, e.g. classes for different colors in your site color scheme, and then include them in various more specific classes as needed. It needs a bit of discipline (e.g. don't define colors anywhere else but in colors.scss, and think each time you @extend it if there's a better way), but gives very consistent and DRY code in the end.

In terms of performance, I think it's essentially a non-issue and not worth worrying about. Debugging is a bigger issue, as too much extending a single class will 'spam' the Chrome/FF CSS developer tools with huge selectors that make it more difficult to track down issues. For statistics, check out http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/

The biggest surprise is how small the delta is from the baseline to the most complex, worst performing test page. The average slowdown across all browsers is 50 ms, and if we look at the big ones (IE 6&7, FF3), the average delta is just 20 ms. For 70% or more of today’s users, improving these CSS selectors would only make a 20 ms improvement.

Optimizing your selectors gives only a 50ms performance improvement at most - and that was data from over 4 years ago, so the difference may well be less than that now. Writing CSS that's designed for maintainability, consistency and reuse is a higher priority IMO, as gains from micro-optimization of it for performance are all but unnoticeable.