Of all the tools we use in web development, CSS is the most susceptible to entropy: the idea defined by the second law of thermodynamics that the amount of information required to completely define the system is increasing. In other words, the quality and complexity of your CSS will only get worse over time.
Programmers make use of object-oriented concepts like modularity, abstraction, and inheritance to reign in entropy in application logic, but such concepts aren’t natively supported by the CSS language and language enhancements like Sass aren’t yet widely accepted by CSS authors.
Why should we avoid CSS entropy?
CSS entropy leads to code bloat, and code bloat is a hurdle to building CSS that is scalable across many pages, many developers, and many users. Obviously, bloated CSS means that you need to download larger CSS files to the user’s browser, meaning greater server and bandwidth requirements, slower page rendering times, and lower page speed ratings from Google. It also increases the number of CSS classes that your developers need to understand in order to code up a page.
Code bloat vs. CSS entropy
Although code bloat is the most readily identifiable symptom of CSS entropy, I want to distinguish between the two concepts. Code bloat encompasses all those extra lines of CSS that separate the current, complete representation of the CSS for your website, from the ideal, minimal CSS required to completely represent your website. In other words, if the ideal, minimal amount of CSS required to represent your website completely is 16Kb, and your current CSS files are 64Kb, then you’ve got 48Kb of bloat.
Code bloat is a static concept, whereas entropy includes an element of time. It is the nature of CSS that it becomes more and more bloated over time. It’s important to make this distinction because we need to be adopting practices in our CSS that reign in CSS’s propensity to bloat as well as the bloat itself.
So how do we do minimize CSS Entropy?
- Avoid using ID tags in CSS selectors. ID tags are not reusable by definition. So every time you use them in your CSS, you are creating an opportunity for entropy. Sure, you can make a good argument that the wrapper div is unique on a page; and that the drop-down navigation is unique as well. But then you get into grey areas, where more often than not, you’ll be wrong in your assumption of uniqueness.
- Define your basic CSS classes before you start laying out pages. Too many CSS classes are created as one-offs to style a single page. You already know you’re going to need an array of button styles, form elements, and a couple of different table styles at the start of the project, so design them up front. This way any customizations you need to make down the road can build upon the existing classes, instead of being built from scratch. Moreover, a strong set of basic CSS classes encourages reuse and discourages customization. The best example of this approach that I’ve found is the MailChimp Style Guide.
- Make your CSS more object-oriented by breaking up your CSS mega classes into small, reusable components. We’ve all seen mega classes like .users-table or .registration-form that define every structural and aesthetic attribute of the HTML element. The thing is, if there’s a users table, there’s also often a products table or a posts table. By separating the structure of the component from the aesthetics (or context) of the component, you can create CSS classes that have a lot more potential for reuse.
- Use CSS language extensions, like Sass, smartly. Sass is great for creating modular and DRY CSS, but it also contains within it the power to generate enormous bloat. Mixins, by nature, create redundant lines of code that must be downloaded to the browser. The @extends directive is preferred because it creates a shared class definitions. And while I love the logical organization allowed by nested class definitions, I’ve found they encourage mega class definitions, rather than small reusable components. (Nesting also increases the number of comparisons the browser must make to match the CSS class to the HTML element, thus slowing rendering time.)
Actively resist CSS’s tendency to degrade by adopting CSS policies that discourage entropy by encouraging class reuse.
If you liked this post, then you’ll love our Scalable CSS Frameworks webinar.
March 8, 2012 at 12pm CT. If your development team is struggling to make your current CSS work, or Google is penalizing your site for slow downloads, you can’t afford to miss this webinar. Learn more