When to Split Style Sheets

Published on March 5, 2009 (↻ February 5, 2024), filed under (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. And if you’re only interested in a robust overview on coding guidelines, check out my little book on it: The Little Book of HTML/CSS Coding Guidelines (updated).

Three factors influence whether it makes sense to split style sheets: probability, meaning (aka semantics), and granularity. Thinking aloud:

  1. Probability has to be considered for all web development decisions. When it’s about splitting up and using separate style sheets, probability is important to e.g. estimate the likelihood of the style sheet to get (too) big, the likelihood of the rules in question to be only temporary, and the likelihood of more people working with the style sheet.

    So if you’re dealing with one style sheet but anticipate it to be growing a lot over the next few months, split it up in meaningful chunks. If you’re just adding a couple of rules for testing, don’t split it up. If you’re the only one working with a style sheet, you might be familiar enough with it to deal with a big one.

  2. The meaning of style sheets or style sheet sections is decisive for split-ups as well. It can make sense to e.g. separate a part of a style sheet that just deals with forms, as forms can make up an own “unit of meaning.” It probably doesn’t make much sense to split that form style sheet up into two style sheets, unless it’s so big as to form other meaningful chunks, or includes other, semantically different types of forms.

  3. Also, there’s granularity. You could create a style sheet for every single CSS rule, even rules that just consist of one declaration. That doesn’t make sense because it’s too granular. You could also put all your corporate identity into one big style sheet, saving a couple of HTTP requests and leveraging caching, but understanding and maintaining 15,000 lines of CSS code of which maybe just 200 are relevant for each request make that approach questionable, too.

(It’s all about the thresholds set for these three variables. Give them good thought.)

An example, you might prefer absolute certainty before adding something to your core style sheet, think that all border styles are a good, meaningful thing and should go into another style sheet, and that you don’t mind fine granularity at all. This could suggest that you’re using a main style sheet, have five others defining fonts and whatnot, and even accept Conditional Comments. (The maintenance penalty for these particular decisions can be costly, however.)

The way I usually treat these variables is a mix of not worrying too much about volatile conditions, thus going for standalone style sheets that might have a “test” section in them. I only (but then very much) split style sheets by meaning when otherwise more than 50% of the rules of the overall style sheet would not be needed in there. And overall, I don’t mind large granularity up to, say, 500 different declarations.

I’m taking this approach because I find it more efficient: On the one hand, separating style sheets means more HTTP requests (unless you have a system in place that combines or “builds” them). On the other hand, style sheet size is not decisive for understandability; this largely depends on CSS organization, like reasonable use of modules or comments.

Was this useful or interesting? Share (toot) this post, become a one-time nano-sponsor, or support my work by learning with my ebooks.

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

  1. On March 6, 2009, 6:24 CET, Judd Lyon said:

    I used to split stylesheets but kept finding myself in odd situations where I couldn’t really classify whether it was a structural or presentational set of declarations. It backfired quickly.

    Suturing them together at build time for big sites seems to be the way to go.

  2. On March 6, 2009, 9:23 CET, Peter said:

    We have developed our own CSS framework which we use to build our applications and websites. We’ve ordered them logically, using internal conventions. We love using our framework, because our team always knows where to look for a certain setting. This makes working with a team much easier.

    As for the amount of stylesheets: in our case it doesn’t matter. When the application / website is live, everything is merged together and presented as a single optimized stylesheet and based on the User Agent.

  3. On March 6, 2009, 15:55 CET, Ben Carlson said:

    For whatever reason I have found myself splitting stylesheets up into layout.css and text.css. I think having all the typography in its own file makes it easier for me to work with and read in. Ideally I would combine these before the site goes live, or have a system in place to combine them automatically, but that usually isn’t the case.

  4. On March 6, 2009, 17:39 CET, Jacob Rask said:

    When using a style switcher with for instance an alternative with higher contrast, I find it useful to have one ’shared’ file for structure, one for type and one for colour & images. That way you’ll only have to serve (and edit) one file at the time. But still, the problem exists on what to put where. When for some reason using line-height instead of a padding, does it change from typography to structure..?

  5. On March 6, 2009, 17:57 CET, Dustin Boston said:

    @Judd I have totally had that problem lately! I am ALWAYS experimenting with the layout but the typography and colors (two distinct stylesheets) have some overlap.

    Here is a system that I have recently started using. Um, it’s a bit anal.

  6. On March 7, 2009, 1:01 CET, Neal G said:

    If you already split your stylesheets into separate files such as layout.css, text.css etc. you could just as easily combine all of those in one file and just separate them within the larger stylesheet. I like to place a table of contents at the top of my stylesheet and then number my sections with comments. I prefer to just include everything in one.

  7. On March 8, 2009, 0:52 CET, Tom said:

    I like to keep as much as I can in one stylesheet, but within it I separate things in three parts; typography, structure, and font stacks.

  8. On March 8, 2009, 13:54 CET, Patrick Steer said:

    I do like Tom all serperated into 3 files typography, structure, and font stacks, this gives a clear and sorted structure - but i think this works only for small or middle sized projects.
    keep on seperating
regards

  9. On March 8, 2009, 17:29 CET, Jonathan said:

    Arg, your article seems interesting, but come on
 All small-CAPS ?!!

    My eyes hurt đŸ˜”

  10. On March 9, 2009, 10:16 CET, Jens Oliver Meiert said:

    Peter, that sounds all cool, except for worries I’d have concerning the “based on the User Agent” part.

    Ben, that reminds me a bit of other “layout” style sheets I dealt with before, where I sometimes struggled to understand why certain “layout” styles went into a different style sheet; this might be due to a different understanding of “layout.” Clearly, at the end of the day it’s important what works for you, especially in the long run.

    Neal, Tom, right, an approach that I just labeled with “CSS organization,” which plays quite nicely with not-too-complex style sheets as well as static environments (where you might not be able to save HTTP requests by merging your CSS files).

  11. On March 9, 2009, 17:25 CET, Peter said:

    @Jens:
    The dicision on which rule belongs in which stylesheet is mainly made for the developer in conventions. Everything else is decided on the go by the developer. Then again, the consequenses of placing a CSS-rule into a ‘wrong’ stylesheet, are nihil anyway.

    The “based on the User Agent” line was basically pointed at IE. We’ve written some server-side scripts (PHP) that enhance user experience in IE (mainly IE6 and lower). IE6 has a hard time rendering modern websites, so we’ve decided to do some of the rendering work on the server if an IE-user visits the website
 It’s way more detailed ofcourse, but that would go offtopic đŸ˜‰

    Peter

  12. On March 25, 2009, 22:29 CET, Thomas | Santhos said:

    I normally do not split them. I always work alone on projects (when it comes to css) and I always find my way in my css file. But I can imagine when working with more people things need to get more structered and it might be handy to split things up into for example navigation, content, etc


  13. On May 9, 2009, 11:03 CEST, Alan said:

    I agree Thomas, I’m fine working myself on a single css sheet. But when I asked my bro to help me out with something it wasnt the style he was used to working and I would have been aswell just taking the time to do it myself.

  14. On May 15, 2009, 20:57 CEST, John said:

    As a web developer of 10 years++ experience my advice is this; If things are starting to get messy in your CSS, then it’s time to separate out the styles. Give your separate style files (and sytles), sensible names, the idea is to help yourself remember what is where at a later date (That’s the whole point of CSS). Basically, it’s down to the developer, the complexity of the site and whether or not someone else will be expected to come along and start working with the design at a later stage.

    I find that even the most complex of designs can be dealt with in one CSS. But maybe that’s just me.

    Nice article BTW.

  15. On May 28, 2009, 0:15 CEST, Glen said:

    Although some of these comments contradict each other, I have to agree with them all. If I’m working on a clients site and the single style sheet is massive, it does a while to get used to. But if it’s my site, I can work with one sheet no problem. I guess it just comes down to what you’re used to. A more structured approach would be needed if working as part as a team though.

  16. On May 28, 2009, 10:33 CEST, Virginia said:

    Thanks for the interesting article. This is sure to help many people. Over the years I have found that web design (CSS included) is an art rather than a science! In the real world when you get down to the nitty gritty of design you tend to just go with what you feel (but based on a proven methodology for sure).

  17. On May 1, 2010, 2:45 CEST, Mark said:

    I think splitting only becomes necessary (or even useful) when sites become highly complex and have teams of developers. Even then I don’t think splitting is done so much out of productivity as actual necessity!

  18. On February 8, 2011, 5:01 CET, Martin said:

    I always aim for one stylesheet wherever possible. It minimises http requests and helps a little in speeding page load times.

    You could alternatively use a caching plugin though that minifies css.