Please read my blog's comment policy here.
KB 262161 outlines the maximum number of stylesheets and rules supported by Internet Explorer 6 to 9.
Some folks have wondered about the math that underlies these numbers. 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. The 5 bit sheetIDs results in the 31 @import limit, and the 12 bit ruleID results in the 4095 rules-per-sheet limitation. While these limits are entirely sufficient for most sites, there are some sites (particularly when using frameworks and controls) that can encounter the limits, requiring workarounds.
There’s a simple test page for the limits here.
Update: IE10 Platform Preview #2 significantly raises the limits described above. In IE10 (any browser/document mode):
Actually the 4095 is a Selectors-per-sheet limitation and not a rules-per-sheet limitation. See this test page: demos.telerik.com/.../4095issues.html. If you add more selectors to an existing rule fewer and fewer rows will be highlighted in red.
@Zoompf: I suspect that internally, the rules are cloned for each selector, leading to the behavior you describe
Does it still use a 32-bit integer in the 64-bit version of Internet Explorer? I would assume it does, given the KB article doesn't exclude the 64-bit compiles from the Applies To section.
@Warren: Yes, it's still a 32bit integer when running 64bit; you can easily observe this by loading the test page in 64bit IE.
Actually, I think this applies to IE3, 4, 5 and 5.5 as well. I thought it was a neat trick when I wrote the code. :)
:-) Thanks for the history! I usually avoid talking about anything before IE6 on the grounds that I don't have either source or VMs for those ancient platforms.
Thanks. Now I feel even OLDER. :)
I'll second Zach's question: Are there any plans to "fix" this? Or at least exapand the limit on 64bit version by using 64bit int?
Especially the 31 imports issue is annoying, it is surfacing in a lot of frameworks and cms systems where you normally pack/compress lots of js files togheter, but in "development mode" you just serve the source files direclty.
@Zach, @Andre: Folks who are new to this blog should understand that its posts do not, as a rule, discuss plans for future versions of IE. In rare instances, the IEBlog (http://blogs.msdn.com/b/IE) will have "forward-looking" posts, but you won't find those here.
But Eric, do you know of a trick to work around this? Can you point me to links? I have more than 31 links in too many pages with 3rd party controls on them.
[EricLaw: I'm not sure what you mean by "trick"-- this is a hardcoded limit in the code. The way to workaround it is to use a smaller number of stylesheets (which probably will improve performance too) by combining or otherwise eliminating sheets.]
http://blesscss.com/ Solves some of the problems...
Pardon me if I read this wrong....but I visited the link to the specs for IE10....and it suggests the limits will be removed COMPLETELY:
Removal of Style Sheet Limits
In Internet Explorer 9 and earlier, there is a limit of 31 style sheets per webpage. There is also a nesting limit of four levels deep for style sheets that are linked using @import rules.
The original post has limits:
A sheet may contain up to 65534 rules
A document may use up to 4095 stylesheets
@import nesting is limited to 4095 levels (due to the 4095 stylesheet limit)
Perhaps MS has updated the web page since you first posted, Eric!
@Tom: The limits I gave are accurate. I'll talk to the owner.
Why have such a limit at all? Chrome, Firefox and Opera all manage to get round the problem but IE10 still can't say it can deal with unlimited selectors. The reason this is such a bad design decision taken by the IE team is that web apps are getting bigger and more complicated. When these apps are minified for improved performance the css selectors all go into 1 file for reduced http requests. Unfortunately in our case this has taken us over the limit. This means that we have to spend additional time to make our app work in IE and thus increasing costs.
EricLaw: Internally, all software must decide how much storage space to allocate for a given variable, and all storage space is inherently limited by the memory and disk available. In the case of IE, the data storage chosen as a 32bit integer, which provides high-performance. In IE10, the allocation of the bits in that 32bit integer was adjusted to better meet the needs of real-world pages, and in practice, we'd never seen a page which did not work with the new allocation pattern. (My guess is that other browsers are either using a 64bit integer, which has an increased memory and CPU cost, or they had a smarter allocation of bits within a 32bit store -- like IE10's -- to start with).