How many commas are too many commas in CSS

Question

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?

Don't worry about performance unless you have a real reason to worry about it, do you? That many commas anywhere is a code smell. — Ruan Mendes, Jul 27 '13 at 08:41
Taking the clearfix for example: I have two options writing it in the html which is nice for reusability but ugly on the html side. Or using a mixing which will rewrite the code many times. What do you mean by "code smell?" I'm just curious would I ever notice slowness from doing this route? — Armeen Moon, Jul 27 '13 at 08:46
I would prefer the `clearfix`for readability to know there is a clearfix on the html element. If you work in a team that's definitely way to go or if another developer is ever gone work on this project. — Dejan.S, Jul 27 '13 at 08:49
@MatthewHarwood, then go with it. I don't see a performance issues with it. — Dejan.S, Jul 27 '13 at 08:53
I see... You're not going to write that code out, you're just asking about any performance hits from the code that scss mixins create? — Ruan Mendes, Jul 27 '13 at 08:57
@Dejan.S I just know there's a rule of thumb for not overly nesting your selectors: ex. #main-navigation header ul li.bestlistitem. For it has to parse each one. I was curious if this may have the same effects to some degree. Another example is using the * selector. — Armeen Moon, Jul 27 '13 at 08:57
The parsing of the selector has nothing to do with the performance. It's how to keep track of everything that matches. * is obvious, you have to update every element. Long queries require a lot of traversing to determine if an element matches a query. Commas? They don't matter, what matters is the content of each selector — Ruan Mendes, Jul 27 '13 at 09:04
@JuanMendes I honestly think the easiest way to answer this is. What would the performce be of 50 clearfix mixins vs 50 commas seperated off one class. — Armeen Moon, Jul 27 '13 at 09:04
It looks to me like you have your A and your B, so go do a benchmark. — cimmanon, Jul 27 '13 at 16:18

Michael Low · Accepted Answer · 2013-07-27T10:56:58.833

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.

Like I said to Matthew, don't be paranoid about performance, thanks for the info and link. Great point about improving the classes themselves, I thought about that but was typing from my phone in bed... — Ruan Mendes, Jul 27 '13 at 17:00

score 1 · Answer 2 · edited Mar 31 '15 at 20:45

1

The parsing of the selector has nothing to do with the performance. It's how to keep track of everything that matches. * is obvious, you have to update every element. Long queries require a lot of traversing to determine if an element matches a query. Commas? They don't matter, what matters is the content of each selector

edited Mar 31 '15 at 20:45

Volker E.

5,911
11
47
64

answered Jul 27 '13 at 09:04

Ruan Mendes

90,375
31
153
217

CAN I BELIEVE YOU ON THIS JUAN?!lol if I had a clearfix with 50 different classes vs a mixin that rewrote the code 50 times... the extend is way better yeah? And I could apply this theory to any class I made. – Armeen Moon Jul 27 '13 at 09:09
No guarantees, it just makes sense in my head. You'll have to test it :) – Ruan Mendes Jul 27 '13 at 09:17
I totally want to... do you know how to even test? This is question I want to really know. I totally think I could build a site just off a handful of these types of classes. – Armeen Moon Jul 27 '13 at 09:19
If you can't time it, you shouldn't be paranoid, that's why I'm not really worried. I could but unfortunately it wouldn't be easy and i don't think it would be worth the effort – Ruan Mendes Jul 27 '13 at 09:22

Ahmed Habib · Answer 3 · 2013-07-27T08:56:05.843

Its not mandatory how much classes you can nest or group but I don't understand your logic behind it. Let me explain with example.

.a{
color:white;
}

.b{
font-size:10px;
}

.c{
background-color:red;
}

in HTML

<div class="a b c">TEST</div>

Why you wanna do this???

You can actually do this

.a{
color:white;
font-size:10px;
background-color:red;
}

in HTML

<div class="a">TEST</div>

Your CSS file is downloaded by the browser so if very hugh CSS style file would take more time to load, please do take it in mind. You are free to add more classes in grouping as you like but the more useless classes will be there the more slower the site will load. It will decrease your performance.

UPDATE

If you are worried about mixing classes over and over again then you should not be worried because that why we have CSS and its classes to use anywhere in the code and declared once at the top. It something like function in php, you can use function anywhere but you can use function with different arguments and hence the result will be difference.

For example in CSS,

.hidden{
display:none;
overflow:hidden;
}

.text{
font-size:10px;
color:black;
}

#id .text{
font-size:20px;
color:green;
}

So now in HTML

if we will use

<diiv id="id">
<div class="text">Text</div>
</div>

and

<div class="text">Text</div>

the results are not same.. :)

this is not my intent. My intent is to write one class and use that class between many html nodes. I will fix the question right now to reference this idea. — Armeen Moon, Jul 27 '13 at 08:34
The op doesn't want always want all attributes of a, b, c. Sometimes just a, sometimes a and c and so on. They are mixins. The op is asking about the best strategy to implement mixins — Ruan Mendes, Jul 27 '13 at 08:44

How many commas are too many commas in CSS

3 Answers3

UPDATE