The reason for that is a rather cute implementation explained here:
http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164...
(...and IMHO 4K selectors is a lot more than any sane page should use...)
I don't think this is a problem with hand-coded CSS files. But since the trend nowadays is to generate CSS from a bunch of LESS or SASS files, minify the whole thing, and stuff it into a single HTTP request, it's not impossible for large and complicated apps to end up with over 4K selectors. When you're living in SASS fairyland you don't always remember that your beautifully nested rules and mixins will compile into dozens of CSS selectors.
Is that 4K of selectors that are all actually used, or are most of them just taking up space? If it's the former, then I can see the concern, but if it's the latter, then maybe the 4K limit is perfectly reasonable after all, and instead we should be rethinking how we generate our CSS (a quick search shows plenty of tools that will find and remove unused selectors.)
Or put another way, it's the difference between complaining about some system not having enough RAM instead of trying to rewrite your application to be more efficient so it can stay within the limits; and I think most recently there's been far too much of the former and not enough of the latter.
Whether or not the extra HTTP requests are worth the time and RAM saved by removing unused selectors will probably depend on your specific needs and priorities. For the time being, though, I suspect that modern computers take less time parsing a few thousand unused CSS selectors than the time it takes to fetch an uncached HTTP resource from a few thousand miles away. Moreover, devices with less RAM and computing power tend to be connected to even slower networks (e.g. 3-year-old phone on a 3G network).
Open gmail, do this in the console:
document.styleSheets[2].cssRules.length
In any case, for large sites with site-wide stylesheets that have styles for everything on the site, it's easy to end up with thousands of rules. A simple example is github, which on the front page has this as of today:
<link href="https://github.global.ssl.fastly.net/assets/github-b836a3967c04ec8b8bfdd101d2226064cb18f45d.css" media="all" rel="stylesheet" type="text/css" />
<link href="https://github.global.ssl.fastly.net/assets/github2-91575e4b8f601c887ca6b13c6f78d06f03af775f.css" media="all" rel="stylesheet" type="text/css" />
The paragon of wondrous design that is the Huffington Post has a bit over 4k rules, spread over 5 stylesheets.
msnbc.com also has a bit over 4k rules, spread over 5 stylesheets.
It's pretty easy to find sites with 2-4k rules (Outlook Web Access, BBC front page, CNN front page, twitter, Google docs, whitehouse.gov, the Facebook login page, officedepot.com, washingtonpost.com, youtube, I'm sure I could find plenty more).
All of which is to say, your typical website has more CSS than most people think.
That it's common for all of these sites, who have massive surveillance and SEO structures built into them, to have gigantic stylesheet collections doesn't change the fact that they are bloated nightmares of code.
If I said, "filing taxes is a nightmare", and you said, "oh yeah, but what about all the other people who file taxes, some of them even more complex than yours?" That wouldn't change the fact that filing taxes is a convoluted, intentionally obfuscated, Lovecraftian construct, summoned forth from the depths of Hades itself.
They have to do with having a site with a wide variety of different-looking pages and wanting to have a single site-wide stylesheet, instead of having dozens or hundreds of smaller stylesheets. Whether that's a useful thing to do or not obviously depends on how your maintenance for the site is set up, how your CDN works, and probably other things I have no idea about; design of this sort of site is not my area of expertise.
And while I agree that all of these sites have a lot of complicated styles and scripts going on, I have a hard time believing that a site of the sort I just described can be created without ending up with a fairly complicated stylesheet.
If your position is that having such a site (variety of different kinds of pages) should be a non-goal, I can't agree with that: there are plenty of reasons to want a site like that. If the argument is that having a single stylesheet to rule them all in that situation is bad for maintainability, I don't have a good response: as I said I've never maintained such a site, so I don't have a good feel for what the maintenance tradeoffs are.
Fully agreed on the taxes. ;)
... especially since it'll be hard to fit more than that into the 640k of memory I have. ;)
http://en.wikipedia.org/wiki/Category:Web_browsers_for_DOS
(Whether they support CSS, and if so, what the limits are, I don't know.)
The solution was of course to simply join the CSS files where possible. But it definitely was a bit of a WTF moment.
Is there a reason for this? Why not just use 3 shorts?
There is always some level of arbitrariness when you represent data structures this way for performance reasons. It's all about what maximum values you think are good enough.
It seems they didn't expand the limits to 64-bit, as that could vastly increase them: e.g. a (5x4):24 split, meaning 16M rules per sheet.... and if you have 16 million rules in a single CSS file, I think it's safe to say the CSS rule limit is the least of your problems. (But then whoever came up with the 4K limit probably thought the same thing...!)
Does anyone happen to know what WebKit/Gecko/Presto does? I've been thinking of writing my own HTML/CSS layout engine and these sorts of things make for interesting decisions on the algorithms to use.