我们知道，在IE的怪癖模式（quirk mode）下，<IMG>元素会忽略所设定的padding。而在标准模式下，则会有padding。

问题是，IE所表现出来的情况说明，整个IE的开发，大量的问题不是从认真修复和从根本上重构，而貌似是不断patch。

举一个例子。最初IE就具有一个bug，即操作scrollbar，会导致控件（如input文本输入框）的focus丢失。为了解决这个问题，MS做了一个补丁，使得body元素上的scrollbar不会抢走焦点。但是这个补丁做得非常之差。第一，这个补丁无法解决其他元素的scrollbar抢焦点的问题，事实上任何一个hasLayout的元素都可能抢走控件焦点。第二，在标准模式下，整个浏览器的canvas从body元素变成了html元素，也就是浏览器window上的scrollbar变成了html元素的scrollbar。结果bug回来了。而标准模式下的body元素的scrollbar（如果有的话），却没有这个问题。可见原本的patch仅仅是对于body元素的一种特定patch。我甚至能想像这个patch的代码逻辑：在scrollbar的scroll相关事件处理器中，如果是在body元素上，则首先记录当前获得焦点的元素，然后执行原先的scroll的处理代码，处理完毕后再把焦点设回去。

这是一个多么低劣的patch！

回过头来看IMG上padding的问题。从原理上判断，IMG元素本身始终是hasLayout的，因此其渲染是由IMG元素本身处理的，估计是直接交由一个图像组件处理的，这可能是它无法处理padding的原因。在标准模式下，要支持padding，这一部分代码肯定要修改。同时，标准模式下，box model也发生变化，width不再包括padding的部分。

代码

上述代码在IE6中打开，首先你可以在图像上按右键查看图像的属性，你会发现其值并非是200*82，而是220*182，是其clientWidth和clientHeight的值。即使图像文件不存在也是同样的结果。

然后请点击add image object这个按钮，会在网页中插入一个Object元素，并且其引用的是一个图像（必须是实际存在的图像）。然后，你可以试着改变浏览器窗口的大小，看到了没有？

图像莫名的放大了。如果仔细观察，你会发现图像恰好缩放为220*182，即算上padding后的大小。如果你现在查看图像属性，结果是240*282。还可以试着缩小浏览器窗口，你会发现当窗口缩小到小于图像的宽度和高度的时候，图片居然会跟着缩小！

通过check image size按钮，可以看到stylesheet的最后计算结果居然是220*182，而在窗口缩小到一定程度的时候，会变得更小。

奇怪的是，如果这个html里有两张图片，就不会出现这个情况。此外，如果img上应用任何width和height的样式，甚至只是设置成“auto”（在上面这个网页里点击reset image size的效果），也能避免出现这种情况。

(来自javaeye  的hax)