This simple table with one absolutely-positioned column renders differently in Firefox (and IE) than in Chrome (and other Webkit-based browsers):
http://jsfiddle.net/WZ6x8/
<div>
<table>
<tr>
<th class="absolute"> </th>
<th> </th>
</tr>
</table>
</div>
* {
margin: 0;
padding: 0;
}
table {
border-collapse: collapse;
table-layout:fixed;
}
th {
border: 1px solid black;
width: 100px;
}
.absolute {
left: 0;
position: absolute;
}
div {
margin-left: 100px;
}
Why is there a difference? Which browser is wrong (according to the standard)? How can this be fixed to work on all browsers, without removing the line border-collapse: collapse
?
Edit: as noted by @urzeit, "If you specify top: 0;
the output in firefox is the same as in chrome." However, there are two issues: first, with multiple rows, top: 0;
collapses them all into one; second, the right edge of the absolutely-positioned column extends one pixel too far. You can see both issues at http://jsfiddle.net/WZ6x8/3.
This is caused by rounding issues which are often inconsistent across browsers, and are probably the same ones that plague things like background offsets, percentage calculations and so on.
In a nutshell, the reason why rounding issues come into play is found in section 17.6.2 which, as you may have guessed, describes the collapsing border model:
Borders are centered on the grid lines between the cells. User agents must find a consistent rule for rounding off in the case of an odd number of discrete units (screen pixels, printer dots).
And:
The top border width of the table is computed by examining all cells who collapse their top borders with the top border of the table. The top border width of the table is equal to half of the maximum collapsed top border. The bottom border width is computed by examining all cells whose bottom borders collapse with the bottom of the table. The bottom border width is equal to half of the maximum collapsed bottom border.
Since the border width is 1 pixel, which is an odd number, rounding issues occur when attempting to halve that value. So the question of which browser is wrong — or if any of them are — is debatable.
Unfortunately, because this is a rounding issue, it's not possible to work around this using pure CSS unless through inconceivably elaborate hackery, and very difficult to do so using a script as browsers tend to be inconsistent when reporting decimal/fractional offset values as well (in particular, Firefox, IE and Chrome all report wildly different values for offsetTop
of your table-cell and its next sibling).
While I can't offer a solution to your problem, hopefully at least I've helped you understand why browsers are behaving the way they do.
Here's the nitty gritty if you're interested in why the issue ultimately lies in the way the collapsing border model is defined.
Section 9.7 states that if an element is absolutely positioned, then its display
is set to block
, even if it would otherwise be a table-cell
. In all browsers, the computed display
for that th
is in fact block
, so no problem there.
As you've correctly pointed out, the containing block of your table cell is the initial containing block. This removes it from its usual containing block which would otherwise be the table. Section 10.6.4 does add that that if your cell does not have any specified height, top or bottom offsets, i.e. they are all auto
, then it should remain in its static vertical position and measurements made accordingly. (Likewise the horizontal position is accounted for in section 10.3.7, however since you've given it left: 0
and width: 100px
, it gets shifted to the left edge and its width is as specified, excluding the borders.)
But what is this static vertical position? Because it would ordinarily be display: table-cell
if it wasn't absolutely-positioned, the static position, and its corresponding measurements, is determined by its position in the table.
Your given table layout is covered by the following subsections of section 17:
Section 17 contains elaborate descriptions on how tables, captions, table-rows and table-cells should be laid out. A lot of it is based on HTML, and certain sections are left vague and/or undefined for various reasons. Fixed table layout is pretty well-defined though, and in this case it is not even relevant.
Section 17.5 says this near the bottom:
The edges of the rows, columns, row groups and column groups in the collapsing borders model coincide with the hypothetical grid lines on which the borders of the cells are centered. (And thus, in this model, the rows together exactly cover the table, leaving no gaps; ditto for the columns.)
And:
Note. Positioning and floating of table cells can cause them not to be table cells anymore, according to the rules in section 9.7. When floating is used, the rules on anonymous table objects may cause an anonymous cell object to be created as well.
Which, of course, has been explained just above.
But if an absolutely-positioned table cell is no longer a cell, what happens?
A "missing cell" is a cell in the row/column grid that is not occupied by an element or pseudo-element. Missing cells are rendered as if an anonymous table-cell box occupied their position in the grid.
So while the actual th
box is absolutely positioned, it leaves an anonymous "ghost" cell in its place in order for the table to be rendered properly. This anonymous table-cell is empty and does not inherit the styles from the actual table-cell, so it has no intrinsic width.
However, because the actual table-cell's vertical position is static, it is still affected by how the table is rendered, which brings us to section 17.6.2 on the collapsing border model.
multiple rows - Try this css..
<style>
.absolute {
left: 0;
margin-top: -1px;
border-right:0px;
position: absolute;
}
@media screen and (-webkit-min-device-pixel-ratio:0)
{
.absolute {
margin-top: 0px;
}
}
</style>
Chrome And Firefox Demo Screenshot.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With