如果有哪一天，你突然发现自己写的的脚本不起作用了，而这一切又只是发生在IE浏览器上，你会怎么办？你是认为自己写的程序有问题呢？还是认为IE处理程序有问题？其实这个问题想都不用想，肯定是我们写的程序有问题。因为我们是程序员，我们要解决的方案就是做一款兼容所有主流浏览器的应用程序。如果应用程序有问题，那就是我们的解决方案不成熟。
这个问题已经发现很久了，只是一直忙于系统功能的开发，而没有去解决浏览器的兼容方案。最近得空，终于有机会去解决一下这个难题，先描述一下这个Bug的表现形式。界面在FireFox等浏览器下页面显示正常，而在IE浏览器下某些CSS样式没有应用上，注意并不是所有的CSS没有起作用，只是有一部分CSS在IE下没有起作用，这里我们可以排除没有引用JS文件或者引用JS路径不正常的问题了。
出现上述问题，我们的第一反应通常都是CSS语法不标准引起的，这些CSS语法在FireFox下可以识别，但是在IE下却不会识别，我们知道不同浏览器处理解析CSS样式表是有一定区别的。不错，我也怀疑自己的CSS语法不规范，但是经过仔细审核后，我发现并非是语法问题。第一，CSS语法采用了标准的通用语法，在各个浏览器下都是相同的；第二，在IE浏览器下，并没有嗅探到相应的class。由此可以断定，应该是那些CSS文件没有被正确引入。
但是我们的CSS文件引入方式都是一样的，并且都是放在CommonThemes同一个文件下进行引用，这样做有两个好处：一是便于管理CSS文件；二是减少了因引用路径不正确而造成的错误。照常理来说，这样做是不该出问题的，然而这也正是那个不按常理出牌的IE的问题所在。
原来在IE浏览器下，通过使用<script type = "javascript"/>来引用文件时，IE仅能识别31个文件。如果在引用的文件大于31个，IE就会自动过滤掉。因为我们将整个系统的CSS文件全都是放在CommonThemes目录下，远远大于31个。所以在第31个CSS文件之后的文件，就不再起作用了。
既然这样，我们就必须把CSS文件分拆放到不同的<script>标签下，以防止一个<script>标签加载CSS文件数量超过31个。我们的解决方案是按照系统的架构及业务需求将CSS引用文件分为多个文件，保证每个文件下CSS的路径数量不超过31个。
IE最多只允许引用31个文件，一般情况下，我们确实不需要在一个脚本下引入这么多的文件。IE之所以这样做，可能是想提高系统运行的效率，防止内存泄露等。只不过仅凭它的一己只想，就进行了文件过滤，实在是大大的不该。别忘了，程序员的目标是解决问题，而非制造问题