alt131 - 7:13 pm on Dec 15, 2011 (gmt 0)
Hi penders, good question - and I too would be interested in others thoughts.
In the end I think it depends on workflow - splitting is often required to accommodate multiple workflows in large organisations with multiple teams/team members. Smaller shops will use pre-existing "libraries" for commonly related items like menus. Probably more like enhanced code snippets really, to save re-writing from scratch. Of course, what happens next is the interesting bit. Those who can't see any benefits of splitting css will drop mine them into the site css file and modify as required - while others won't - although i wil note that has led to people like Nichole Sullivan who speacialise in uuntangling the redundancy, duplication, over qualification and download implications.
Nyteshade, good spotting on the Souder article. Also note the date: 2009, and compare to Keith's book which is 2005. Actually it isn't that the coding community didn't know or care about download speed in 2005, it's just that ... well, I'm not really sure what happened around then <sigh>. Jeremy Keith is very well respected, and part of the group of people pushing for a much more accessible and efficient web, so hard to argue. But in terms of your original question I would note three things.
1. The css for a website of around 100 hundred pages should be small enough to keep in one file. If it's not, then I would look for redundancies, inefficiencies, and maybe too much over-qualified code causing it to bloat.
2. The system of organisation should be intuitive and have some relationship to something. Per the recommendations margin and padding are part of the box model. That's layout. I would never consider them to be part typography, and cannot imagine any logical reason to put the margins of the same element in a different file to the element's padding. I don't think humans (unless following Keiths book) would think to look for them in different files either, and user agents don't expect code to be written that way.
3. The flaw in that sort of approach (IMO) is that takes a micro-level focus on the code itself - the property/values (form) - it isn't looking at the macro level of what code does - style HTML elements (function).
Of course I'm fascinated by the micro-detail of css, but that's because I believe increased knowledge will make it easier to write clean, simple code that will deliver content to the user as efficiently as possible. That Keith's approach leads to trying to split a property that is not designed to be split, just so the values can be re-classified so they can then be written into completely different files when that does improve delivery to the end-user highlights the difference between focussing on the form of the code, not the function it is supposed to perform.