更加坏的事情是，即使你仅仅针对IE设计，不考虑其它浏览器，由于IE模型绝对可以说是一只让人难以捉摸其脾气的怪物，所以你单纯为IE设计也会遇到众多难题，发现很多的效果总是绕来绕去都难以实现。
我们都知道，XHTML+CSS的目标就是实现内容与表现分离，理论上对于任何特定一份内容，我们都可以通过CSS实现任何我们想要的表现形式，或者细致地说是布局形式。虽然现实与这个目标有一定差距，但是CSS已经能够满足大多数常见的布局需求，这有CSS Zen Garden为证。然而如果你用的是IE，因为它难以捉摸，所以如果你想用一种简单优雅的CSS去让IE能够实现“任何你想要的布局形式”，那是不可能的，只有复杂繁缛的CSS才能够在IE上满足你的需求。我曾经提到过一种理论，“一个人对一个研究方向是否感兴趣很可能是完全靠偶然事件决定的，这就好像人第一次打羽毛球，如果你赢了几盘你就会感兴趣，如果你一直都赢不了你就会没兴趣”。IE在需要复杂繁缛的CSS这一点上，就足以令大多数的入门者却步。你总感觉到不得要领，你自然没兴趣学下去。
举一个例子说明这个问题，例如你不知道IE有hasLayout这回事，一个元素是否hasLayout对它的布局方式有重大影响，于是你肯定用最简单的思维去思考CSS，认为不同的CSS规则之间应该是松耦合的。“CSS应该被设计为简单优雅的”，你肯定会这样想，没错，它确实被设计为这样，不过IE不是这样去实现CSS罢了。我们用下面的代码去证明IE在quirks mode与standards mode之间的区别：
Hello
Hello
首先，我们用quirks mode看看结果如何，并且一个初学者看到这样的结果会去如何理解CSS规则。在quirks mode中，我们可以看到背景为红色的
包含了上面1行的文本，以及下面向左浮动的以上规则是完全错误的，一个懂得标准CSS以及理解quirks mode的设计师将会如此解释他的理解：
好了，相信这个对比足以说明问题的严重性了，通过IE的效果去理解CSS，最终只会让你的理解与真实的CSS相差甚远。详细的standards mode与quirks mode带来的标准执行差别，可以参考这篇文章：CSS Quirks mode and strict mode。
然后肯定有人要问我，如果通过doctype确保使用的是standards mode，那是不是就没问题了呢？standards mode确实会让IE对CSS的解释合理很多，但事情并没有那么简单，这你可以通过实践去慢慢体会。你可以尝试在standards mode中设计CSS，并且尽力保持它们在IE/FF/Opera/Safari这4大主流浏览器中显示一致，随着设计的进行，你会发现这不是那么容易做到的。或许你不乐意花时间去fix其中的一些小问题，宁愿任由其中一些浏览器的用户看到比较丑陋的布局，但至少你已经了解到一个和上面例子类似的道理：不同浏览器即使同样在standards mode，其对CSS的理解仍然有所差异，而差异当中最多只可能有一个是正确的，甚至可能全部都是错误的。这篇CSS contents and browser compatibility就列举了众多浏览器对CSS支持的差异，一份CSS总会因为其中有一些规则在某些浏览器上是不支持的或者是buggy的，而导致你难以保持它们在不同浏览器上显示一致。
接下来可能还有人会问我，既然IE的市场份额最大（特别是在入门级的用户当中），又或者说我的客户指定使用IE作为客户端，仅仅针对IE设计CSS不好吗？为什么要针对FF之类的标准浏览器设计CSS然后再为IE进行fix？因为IE难以捉摸的脾气，让你无法将它的行为理解为一种简单优雅的规则，然后让你陷入CSS规则高度耦合的困境中。请看下面的例子：
HelloHello
现在，你在IE中看到的效果应该是左边出现，然后两个
这时候第一个
完全容纳了最后，如果你已经有了一定的CSS基础，对CSS规则都理解无偏差，却缺乏组合CSS规则的想象力，无法做到所谓的“实现任何你想要的布局效果”，这也就是说，你的内功已练成，仅仅差一些表面的套路，这时候我推荐你去看《CSS Mastery/精通CSS》。看完这本书，相信你只会觉得自己缺乏布局的创造能力，而不会有布局却不知道如何实现。另外，如果你关注CSS方面的内容，可以考虑订阅我的blog：
过年之后，我可能会写一些与ASP.NET+CSS有关的文章，因为现在ASP.NET+CSS的开发并不方便，即使用了ASP.NET 2.0 CSS Friendly Control Adapters也如此，因此需要根据自己的实际情况定制配对的Control Adapter才能解决问题，这就是我接下来要研究的事情。
