Although in many cases height and width just work in Internet Explorer they are not really the same as the ones described in the CSS2.1 specification. A common bug filed against non-IE browsers is that they do not allow width or height to be applied on an inline-level A or SPAN element. IE actually does do that and makes the element an inline-block (or at least, that is how it looks, how it really works is probably something you wouldn’t want to know). That doesn’t work the other way around, a block-level element can not became an inline-block. (Note that by block-level I mean an element with display:block applied to it, not the HTML4 definition of block-level elements.)
This is quite a nice feature of Internet Explorer, except that it shouldn’t work. If IE7 doesn’t implement display:inline-block and keeps this behavior we are probably happy. As when Mozilla and Opera finally implement display:inline-block we can use it in a way that is compatible with Internet Explorer. Note that there is an implication here, that being backwards compatible for non-IE browsers is not really a must have. Note also that I mentioned that Opera should support display:inline-block as well. And although Opera does have some support for it, it is buggy and therefore it should support it.
Let’s get back to the height and width attributes. The behavior Internet Explorer attaches to these properties is really interesting and most of the times it is similar to min-width and min-width as defined by CSS2.1. (This does indeed make all the screaming for support of these properties a bit dubious and it is. What we “should” want is support for height and width and perhaps for max-height and max-width. (And let the current height and width properties be renamed to min-height and min-width plus perhaps some additional fix up of these properties.)
You could also compare it to tables, where height and width actually do have a different meaning and there min- and max- variants generally don’t apply. A simple example to explain the behavoir might be helpful. I once saw the following code in bug report against Mozilla:
p{ height:20px; background:lime }
… most people seem to expect that when there is enough text in the P element to make it higher than 20px the height of the P element should stretch. While in fact, the P element should generate overflow of which the initial value is visible. Only the height:20px and perhaps some padding that was there by default should get a green background. The area that generated the overflow however, should not.
It is of course a pity that IE doesn’t support these properties properly. It is also a pity that they don’t support the min- and max- variants of course, but those are just an unimplemented feature. (Every browser has those.) However, if IE didn’t implement height and width as they did now, other browsers would probably have less useless bugs filed against them, but CSS layouts would have been quite limited.
In fact, when strict mode is enforced by a strict doctype, IE does not automatically add display: inline-block to inline elements. You then need to specify display: inline-block on your own to get the quirks mode equivalent.
It also starts to respect the min-height and min-width properties but only when these are applied to table cells, rows, columns or whole tables.
I also forgot to add that in strict mode it starts to treat width and height the right way (rather then substracting padding from them before displaying).
Note that Opera 7 mimics MSIE in Quirks mode by setting inline elements to inline-block when a style applies width and/or height to them.
Also note that Opera 8 will probably drop this specific Quirks mode feature, because we found that MSIE does not do it exactly this way, and Opera's handling caused problems in a few places.
"Most people seem to expect that when there is enough text in the P element to make it higher than 20px the height of the P element should stretch. While in fact, the P element should generate overflow of which the initial value is visible. Only the height:20px and perhaps some padding that was there by default should get a green background. The area that generated the overflow however, should not."
Isn't this impractical? Shouldn't the overflow also be lime, because that would look best? Shouldn't standards be less about technicalities and more about practicalities for everyday use?
Perhaps for that use case, but I have encountered some cases where this is not desired. And furthermore, standards provide min-height which is exactly what you really meant to be using.