绝对定位的表头（th） - 哪个浏览器是错误的？ [英] Absolutely-positioned table header (th) - which browser is wrong?
问题描述
< DIV>
< table>
< tr>
< th class =absolute>& nbsp;< / th>
th& nbsp;< / th>
< / tr>
< / table>
< / div>
* {
margin：0;
padding：0;
}
表{
border-collapse：collapse;
table-layout：fixed;
}
th {
border：1px纯黑;
width：100px;
}
.absolute {
left：0;
位置：绝对;
}
div {
margin-left：100px;
}
为什么会有差异？哪个浏览器错误（根据标准）？如何解决在所有浏览器上工作的问题 $ border = b $ b 编辑：如@urzeit所述，如果指定 这是由于四舍五入问题导致的，这些问题通常在浏览器中不一致，可能与困扰背景偏移，百分比计算和等等。 简而言之，四舍五入问题的原因可以在第17.6.2节，正如你可能已经猜到的那样，它描述了折叠边框模型： 边框以单元格之间的网格线为中心。用户代理在奇数个单位（屏幕像素，打印机点）的情况下必须找到一致的规则来舍入。 和： 表格的顶部边框宽度是通过检查所有用表格顶部边框折叠顶部边框的单元格来计算的。表格的顶部边框宽度等于最大折叠顶部边框的一半。通过检查底部边界与表底部折叠的所有单元格计算底部边框宽度。底部边框宽度等于最大折叠底部边框的一半。 由于边框宽度为1像素，这是一个奇数在尝试将该值减半时会发生数字，舍入问题。因此，哪个浏览器是错误的 - 或者它们中的任何一个都是 - 是有争议的。 不幸的是，由于这是一个四舍五入的问题，除非通过不可思议的精巧hackery，否则无法使用纯CSS来解决此问题，而且使用脚本非常困难，因为在报告十进制/小数偏移量值时浏览器往往不一致（特别是Firefox，IE和Chrome all 会为您的表格单元格及其下一个兄弟元素的 如果您对为什么问题最终位于折叠边框模型的定义方式感兴趣，请点击这里。 9.7节如果一个元素是绝对定位的，那么它的 正如您已经正确指出的那样，包含块单元格是初始包含块。这将它从通常的包含块中删除，否则它将成为表格。 第10.6.4节的确补充说明如果你的单元格没有任何指定的高度，顶部或底部偏移量，即它们都是 但是是这个静态垂直位置？因为它通常是 您给定的表格布局由第17节： top：0; ，则firefox中的输出与chrome中的输出相同。但是，有两个问题：首先，有多行， top：0; 将它们全部合并为一个;其次，绝对定位的列的右边缘延伸一个像素太远。您可以在 http://jsfiddle.net/WZ6x8/3 查看这两个问题。
offsetTop 报告大致不同的值）。
<尽管我无法为您的问题提供解决方案，但希望至少我已经帮助您理解了浏览器为什么表现如此。
显示被设置为 block ，即使它本来是一个表细胞。在所有浏览器中，对于 th 计算的显示实际上是 block ，所以没有问题。
auto ，那么它应该保持在其静态垂直位置并且相应地进行测量。 （同样，水平位置在 10.3节中说明。 7 ，然而，既然你已经给它<0 c $ c> left：0 和 width：100px ，它会被移位到左边缘，其宽度与指定的一样，不包括边框。）
display：table-cell ，如果它没有被绝对定位，静态位置及其相应的测量值由它在表格中的位置决定。
第17节详细说明了应该如何布置表格，标题，表格行和表格单元格。它很多都是基于HTML的，并且由于各种原因，某些部分保留模糊和/或未定义。固定的表格布局是非常明确的，但在这种情况下，它甚至没有相关性。
第17.5节说明底部附近：
折叠边界模型与单元格边界居中的假想网格线一致。 （因此，在这个模型中，行在一起完全覆盖表格，不留空隙;对于列也是如此）。
以及：
注意。表格单元格的定位和浮动可能导致它们不再是表格单元格， 第9.7节中的规则。当使用浮动时，匿名表对象上的规则也可能导致匿名单元对象被创建。
当然， ，已在上面解释过。
但是，如果绝对定位的表格单元不再是单元格，发生了什么？
A 丢失的单元格是行/列网格中未被元素或伪元素占据的单元格。缺少的单元格就像一个匿名的表格单元格在网格中占据它们的位置一样。
所以，当实际的 th 框是绝对定位的，它会在其位置放置一个匿名的鬼单元，以便表格正确呈现。这个匿名表格单元格是空的，并且不是从实际的表格单元格继承样式，所以它没有内部宽度。
然而， ，因为实际的表格单元格的垂直位置是静态的，它仍然受到表格渲染方式的影响，这使我们看到了第17.6.2节关于折叠边界模型的内容。
This simple table with one absolutely-positioned column renders differently in Firefox (and IE) than in Chrome (and other Webkit-based browsers):
<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.
这篇关于绝对定位的表头（th） - 哪个浏览器是错误的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
