Jens Oliver Meiert

When to Split Style Sheets

Post from March 5, 2009 (↻ March 30, 2016), reflecting Jens the .

This and many other posts are also available as a pretty, well-behaved e-book: On Web Development.

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

(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 what not, and even accept Conditional Comments. (The maintenance penalty for these 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.

About the Author

Jens Oliver Meiert, photo of December 23, 2015.

Jens Oliver Meiert is a German philosopher and lead developer (Google, W3C, O’Reilly). While also identifying as a citizen and author, he’s mostly testing the waters as an artist and adventurer. Here on he shares—and generalizes and exaggerates—some of his thoughts and experiences.

If you have any questions or concerns about what he writes, ask him to explain, or share your own position by sending a constructive comment or email. (Then, if you think something could be of interest to Jens, recommendations for excellent literature are always welcome.)

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:

    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 ;)


  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.

Read More

Have a look at the most popular posts, possibly including:

Or maybe say hi on Google+, Twitter, or LinkedIn?

Looking for a way to comment? Comments have been disabled, unfortunately.

Found a mistake? Reward! Email me,

You are here: HomeArchive2009 → When to Split Style Sheets

Last update: March 30, 2016.

“No epidemic or illness or natural disaster […] will kill a person who does not want to die.”