Apr 27, 2010 at 3:50 PM
Edited Apr 27, 2010 at 10:03 PM
I first like to say, I love this project. It was easy to integrate into our project's build event and it works like a charm. I'm only using the YUICompressor for CSS, as we had previously wrote an in-house JS compressor and manager.
My question, or concern, is the 4096 CSS selector limit per file in IE. I know that is a LOT of selectors, and any sane developer/designer should never reach that limit. I did a rough count of our compressed/combined css file and we are 30% or so of the
way there. Chances are this will never be an issue, but I don't' like to leave things up to chance. I wish I could say our web-app uses a modular based CSS approach, but we don't. We use the theme concept in ASP to provide unique branding/styles per customer,
so all styles are included on every page.
Do you have a workaround/solution to this potential problem? I've looked through the docs and some of the source code and I can't find anything that seems to account for this IE limit. I've came up with a few ideas to try and workaround this potential problem,
but I'm not that happy with them.
The quick, easiest, and least clever of them is to just run 2 compressor tasks, one for css files staring with a-m the other for n-z. That's not really fixing the problem, it's just theoretically doubling the time it takes for the problem to occur.
Another idea I had was to modify the source code to somehow count the number of selectors and insure the max will never hit one file. This has a few problems, first of which being how do you count selectors and of course how do you make the compressor output
multiple css files, but not multiple js files.
I could enforce a count selector limit on the individual uncompressed css files (no way to enforce this, just have to be a rule), then I could modify the compressor to say, only put x files per 1 output file. This kind of destroys the ability to have css
files broken down logically as one might reach limit and have left over definitions.
Again just looking for an idea or a recommendation to this potential problem. My team and I don't feel comfortable leaving it as it. Trying to not leave a trap that we'll spring years down the line. Thank You