折叠边框模型在Web浏览器中的实现是否有效？

Question

我一直试图从CSS 2.2规范中理解this excerpt一段时间没有成功（粗体选择是我的）：

  

UAs必须为表计算初始左右边框宽度   检查表格第一行中的第一个和最后一个单元格。表格的左边框宽度是第一个单元格折叠左边框的一半，而且是   表的右边界宽度是最后一个单元格右侧折叠的一半   边界。如果后续行具有较大的折叠左右边框，   然后任何多余的溢出物进入桌子的边缘区域。

     

通过检查所有单元格来计算表格的上边框宽度   使用表格的顶部边框折叠其顶部边框。顶部边界   表的宽度等于最大折叠顶边的一半。

这就是Chrome中实现边框，折叠等的方式（FF和IE＆gt; 7是相同的）：

table {
  border: 6px solid green;
  border-spacing: 0;
  border-collapse: collapse;
}
#cell_1_1 {
  border: 28px solid red;
}
#cell_2_1 {
  border: 12px solid chartreuse;
}
#cell_2_2 {
  border: 2px solid cyan;
}

虽然我期待这样的事情：

我期待桌子的左边框厚14 px。因为第一个单元格#cell_1_1的折叠左边框宽度为28px（表格的左边框宽度是第一个单元格的左侧边框折叠），左侧是边框在单元格和表格之间分开。因此，在视觉上，该表在第一个单元附近具有28px边界，但是14px属于第一个单元的边界。然后表格的左侧边框保持不变。如果某个单元格的边界较宽，则它们会向左突出，而不会影响桌子的左边界。

与上边框相同。

此外，我认为问题可能与摘录中的初始字有关，即这些规则仅适用于表没有指定边框，但结果与之无关（删除表格的边框样式规则只是删除了绿色边框。

所以任何人都可以回答下一个问题：

• Chrome，FF，IE中此折叠边框模型的实现是否正确？

• 如果它们是正确的，我对规范的理解有什么问题？

现在，如果我们反之亦然并假设Chrome中的实现作为推导规范的起点，那么应该类似于下一个（我只保留了与之相关的部分）左边界为简洁）：

  

UA必须计算表 的初始左右边框宽度，然后将其用于相对于其包含块 的位置。   检查表格第一行中的第一个和最后一个单元格。在所有边界冲突（如果有任何已解决）后，表格的左边框宽度是第一个单元格的左侧边框 的一半

     

...

     

如果后续行的左右边框折叠较大，   然后任何多余的溢出物进入桌子的边缘区域。

     

...

     

任何溢出边界的边界都会被考虑在内   确定表格是否溢出某些祖先（请参阅＆＃39;溢出＆＃39;） ，但不会影响表格相对于其包含块的位置

然后摘录会有意义。

这里有一个表格，边框比第一个单元格宽，在一个包含粉红色背景的块中（我们可以看到，表格的边框是在第一个单元格的边框上选择的，因为它更宽，然后这个边框用于将桌子定位在容器内。后续单元格的较宽边界突出于桌子的边界之外）：

这里有一个相同的表格，第一个单元格的边框比表格的边框宽，在边界冲突解决期间选择它。此处此边框用于相对于容器定位表：

Answer 1

答案是“不”。我喜欢CSSWG讨论的坦率，current draft of the CSS Tables 3 editors' draft上的注释告诉你关于这个问题你需要知道的一切。

  

自浏览器   如此不同地处理这个问题，没有收敛就不会发生   重新实现。 ...

     

......有些组合不是很好的问题，所以没有   渲染算法可能是最优的。

     

因为它们从简单的（HTML）发展成为非常的东西   复杂（HTML + CSS）， Web浏览器使用的当前表格渲染模型是疯狂的（从某种意义上说，它们是   越野车，不可互操作，根本不是CSSish）。很多平常的CSS   假设被打破，效果图差异很大。

（强调补充。）

当前草案中有更多信息，但CSS工作组承认（1）浏览器实施不一致，（2）甚至他们自己当前的提案也不够。