This is basically an explanation of why CSS2.1 should adopt Opera's collapsed table border handling.
The background of an element, in CSS2, is bounded by the element's border box.
In CSS2, a border-collapse table's borders are half within the table's width and half in the margin area. This gives the table an external edge effect similar to what happens internally:
The rule, however, is not very clear about what happens when the margin is not wide enough, and it has been altogether ignored by several implementations: They include the outer half of the border in the table's border box.
Although in some cases this looks awful:
it can be justified in others:
The backgrounds of internal table elements are explicitly
defined to be bounded by the collapsed borders' mid-line. Thus, even with
this border-in-border-area model, the border-in-margin interpretation
can be effected by setting the background on internal table elements
(like rows) instead of on the table itself. In more complex cases
involving image backgrounds, the proposed CSS3
property can be used to pull the background boundary in to the mid-line.
However, there is problem of determining where this outer edge is. In border-collapse mode, the outer edge of the table is not necessarily constant: If the border of a table cell along the edge of the table is thicker than that of the table itself, the collapsed border along that section will be thicker than the rest of the border.
If the outer edge of the widest border is taken as the table's border edge, this will cause the background to overflow the border's visible boundary in sections with a narrower border:
The better solution is to use instead the outer half of the table's own border. In other words, the distance between the border and padding edges is half the table's specified border-width. All borders along the able's edge are guaranteed to be at least this wide (except where a border is hidden, in which case there is no visual boundary to overflow in any case). This method can cleanly handle the common cases where the table border is the thickest, and it renders cases with thicker internal element orders without being aesthetically awkward.
Note that this width can be calculated without knowing the properties of cells and rows further down; it can be calculated at the start of the table layout pass. And it is consistent in how it treats borders throughout the entire table.
The above method effectively deals with the background boundary. However, there is still the problem where thick internal elements' borders overflow the table's margin box, overpainting adjacent content such as the containing block's border.
Relying on margin-setting to pad overflowing borders introduces an unnecessary dependency between table margins and borders. This is also fundamentally inconsistent with behavior in other contexts, where a zero margin will not cause overlap.
Furthermore, the margin-setting workaround cannot handle centered tables. If the margin on both sides is 'auto' and the table is wide enough to fill the containing block, there will be no margin to pad the borders.
The solution is simply to take the difference between the widest collapsed border width and the table's border width and add it to the table margin. This way, margins will be adjusted to measure from this widest visible table edge.
To accommodate one-pass table layout algorithms, the UA may use a just-check-the-first-row heuristic for the side borders.
In the collapsing borders model, the distance between the table's padding and border edges is given as half the width of the table's specified border.
So that thicker borders that collapse with the table border do not overflow the table's margin box and overlap adjacent content, the margins are adjusted by adding to them the difference between half the widest collapsed border's width and half the table's own border's width. If fixed table layout is triggered, the UA must use only the first row in calculating the widest collapsed border for the left and right sides.