On 2008-05-01, Jukka K. Korpela <jk******@cs.tut.fiwrote:
Sub titulo "Re: DIV borders different in IE7 when in td"
scripsit Ben C:
>Table cells should never go narrower than the minimum width required
by their contents. Normal flow block boxes (like default DIV) get the
width you set, overflowing if necessary.
This seems to be the heart of the matter, and I'm trying to get a real
discussion started, by moving the discussion to the right group
(c.i.w.a.stylesheets) and changing the Subject line.
It seems to me that IE 7, specifically in "standards mode" (!),
misbehaves when a table cell has a declared width but the actual width
is larger, due to the requirements of its content. When the <tdelement
contains a <divelement, IE 7 expands the <tdbut not the <divinside
it. This can be seen from the background or border of the <div>, if set,
and even the formatting of its textual content.
However, width calculation is mystic area in CSS, so it might be
possible that under some weird interpretation, IE 7 is "right", though I
cannot see how.
Demo: http://www.cs.tut.fi/~jkorpela/www/width-bug.html
CSS 2.1 10.3.3 is very clear that the div's used width should in this
case (since all horizontal properties are auto) be equal to the width of
its containing block.
The containing block is formed by the content edge of the table cell.
So what is its width?
The computed value of the table-cell's width is "100px". But the used
value of its width is the width required by the long word (it depends on
your font, about 280px in my browser).
My hypothesis for the cause of the bug here is that when IE7 comes to
implement the rules in 10.3.3 for the div, it looks up the computed
width on the td and so gets 100px as the containing block width. It
should instead be looking up the used width [1].
It then solves the equation in 10.3.3 for 100px giving the div a used
negative right margin of about -180px.
So where does the spec say that "width of the containing block" in
10.3.3 means used width and not computed width"?
Well 10.1 says:
2. [..] the containing block is formed by the content edge of the
nearest block-level [p. 117], table cell or inline-block ancestor
box.
"Content edge" is defined in 8.1, as the rectangle given by the "width"
and "height" of the box.
A bit later in 8.1 it says:
The dimensions of the content area of a box — the content width and
content height — depend on several factors: whether the element
generating the box has the 'width' or 'height' property set, whether
the box contains text or other boxes, whether the box is a table, etc.
Box widths and heights are discussed in the chapter on visual
formatting model details [p. 157] .
Clearly this is the used width and height they're talking about, not the
computed width and height.
[1] You possibly get this only in strict mode because it has got conflated
internally within IE with the need not to honour percentages of auto
height table cells in strict mode. In quirks mode browsers will allow
percentage heights of auto height cells for which they have to use
"used" values. In strict they should ignore such percentages.
