> (...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.
I've run into this before with a large app: bootstrap + font awesome + plugins + custom css in a single blob put me well over 4096 selectors. Fortunately, bless (via grunt-bless) and a simple IE conditional comment fixed it for good. Bless is a great project.
Isn't @Import a bad idea? At least if you write multiple <link>s for css they can download in parallel. @Import will always have to wait for the first sheet to download AND Execute. Which isn't so bad with CSS but still.
it's not impossible for large and complicated apps to end up with over 4K 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.
Sure, you could remove unused selectors, but then you'll end up with different CSS files for different pages. That's a lot of extra HTTP requests for a first-time visitor who wants to look around your website.
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).
> (...and IMHO 4K selectors is a lot more than any sane page should use...)
Open gmail, do this in the console:
document.styleSheets[2].cssRules.length
As of today I see "7343". It's possible they only do that in browsers other than IE9, of course.
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:
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.
Uhm, are these supposed to be arguments against me?
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.
The large stylesheets have nothing to do with the SEO bits.
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.
I never had this problem and wasn't aware of it, but I'm glad to know it, because it sounds like something awfully hard to debug if you don't know what's up.
I haven't run into that limitation yet, but I've had a client site which suddenly had started looking broken in IE. It turned out that it had exceeded the 31 stylesheets/style tag limit. This was a site where the CMS theme/template set a few styles, but then was packed with extra widgets loading up to 10 styles each.
The solution was of course to simply join the CSS files where possible. But it definitely was a bit of a WTF moment.
>The root of the limitations is that Internet Explorer uses a 32bit integer to identify, sort, and apply the cascading rules. The integer’s 32bits are split into five fields: four sheetIDs of 5 bits each, and one 12bit ruleID
Is there a reason for this? Why not just use 3 shorts?
Because a single integer is much faster and easier to operate on than 3 separate pieces, and doing a single array sort to compute cascade order is a great idea because of how simple it is.
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.
Is there a reason for 3 shorts? Why not use a 64-bit integer, etc.
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.
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...)