在Web浏览器中折叠边框模型的实现是否有效？ [英] Is the collapsing border model's implementation in web browsers valid?

问题描述

我一直在试图了解CSS 2.2中的

我期待这样的情况：

< a>

我期望表的左边框是14像素厚。因为第一个单元格＃cell_1_1 的折叠左边框宽度为28像素（表格的左边框宽度为第一个单元格的折叠左边框的一半），在左侧，边框在单元格和表之间分割。所以视觉上表格在第一个单元格附近有28像素的边框，但14像素属于第一个单元格的边框。然后边界对于桌子的所有左侧保持相同。

与上边框相同的东西。

如果某些单元格的边框宽度较大，则它们会向左突出，而不会影响表格的左边框。

我认为这个问题可能与摘录中的初始字有关，也就是说这些规则仅适用于表没有指定边框的情况，它原来是不相关的（删除的边框样式规则表格只是删除了绿色边框）。

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

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




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

---

现在，如果我们反过来，并假设在Chrome中的实现作为推导规范的起点，这部分应该是接下来（为了简洁，我只保留了与左边界相关的部分）：

UA必须计算初始的左右边框宽度，然后通过检查表格第一行中的第一个和最后一个单元格，通过
将表格 相对于其包含块 表格的左边框宽度是第一个单元格已折叠左侧边框的一半

...

如果后续行具有较大的折叠左右边框，则
会溢出到页边空白区域。 / p>

...

当
确定是否存在溢出到边距的边界时该表溢出了一些祖先（参见overflow） ，但不影响表相对于其包含块的位置

< blockquote>

然后这段代码就有意义了。

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

< a>

这里有相同的表格，第一个单元格的边框比表格的边框宽，在边界冲突解决过程中被选中。这里，这个边框用于相对于容器定位表格：

< a>

解决方案

答案是不。我喜欢CSSWG讨论的坦率性，以及关于 CSS表格的当前草案的注释

由于浏览器
会处理这个问题，因此您必须了解这个问题。不同的是，如果没有
重新实现，则不会发生收敛。 ...

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

由于它们从简单的（HTML）到非常复杂的
（HTML + CSS），当前表格渲染模型...被web浏览器使用是疯了是
buggy，不能互操作，不是CSSish）。

（强调已添加。）

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

I have been trying to understand this excerpt from CSS 2.2 specification for a while with no success (the bold selection is mine):

UAs must compute an initial left and right border width for the table by examining the first and last cells in the first row of the table. The left border width of the table is half of the first cell's collapsed left border, and the right border width of the table is half of the last cell's collapsed right border. If subsequent rows have larger collapsed left and right borders, then any excess spills into the margin area of the table.

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.

And this is how borders, collapsing etc. are implemented in Chrome (FF and IE > 7 are the same):

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;
}

While I was expecting something like this:

I was expecting the left border of the table to be 14 px thick. Because the collapsed left border of the first cell #cell_1_1 is 28px wide (The left border width of the table is half of the first cell's collapsed left border) and on the left the border is split between the cell and the table. So visually the table has 28 px border near the first cell, but 14 px belong to the border of the first cell. And then the border stays the same for all the left side of the table. If some cell's borders a wider then they are protruding to the left, without affecting the left border of the table.

The same thing with the top border.

Also I thought the problem can be related to the initial word in the excerpt, that is these rules apply only in case a table has no specified border, but it turned out to be not related (the removal of the border style rule for the table simply removed the green border at all).

So could anyone answer to the next questions:

• whether the implementations of this collapsing borders model in Chrome, FF, IE are correct?

• if they are correct, what is wrong with my understanding of the specification?

---

Now, if we went vice versa and assumed the implementation in Chrome as a starting point to derive the specification, this part should have been something like the next (I have kept only the part relevant to the left border for succinctness):

UAs must compute an initial left and right border width for the table which is then used to position the table relatively to its containing block by examining the first and last cells in the first row of the table. The left border width of the table is half of the first cell's collapsed left border after all border conflicts if any have been resolved

...

If subsequent rows have larger collapsed left and right borders, then any excess spills into the margin area of the table.

...

Any borders that spill into the margin are taken into account when determining if the table overflows some ancestor (see 'overflow'), but do not affect the position of the table relatively to its containing block

Then the excerpt would have made sense.

Here there is a table with the border wider than the first cell's one inside a containing block with the pink background (as we can see, the border of the table is chosen over the border of the first cell because it is wider and then this border is used to position the table inside the container. The wider borders of the subsequent cells are protruding beyond the table's border):

And here there is the same table with the border of the first cell wider than the table's one, that is chosen over it during the border conflict resolution. And here this border is used to position the table relatively to the container:

解决方案

The answer is "no." I love the frankness of the discussions had by the CSSWG, and the notes on the current draft of the CSS Tables 3 editors' draft tell you all you need to know about this question.

Since browsers handle this so differently, convergence cannot happen without reimplementation. …

… some combinations are not well-posed problems, so no rendering algorithm could be optimal.

Because they grew from something simple (HTML) to something very complex (HTML+CSS), the current table rendering models…used by web browsers are insane (in the sense they are buggy, not interoperable and not CSSish at all). Many usual CSS assumptions are broken, and renderings diverge widely.

(Emphasis added.)

There's much more information in the current draft, but the CSS Working Group acknowledges (1) that browser implementations are inconsistent, and (2) even their own current proposal is insufficient.

这篇关于在Web浏览器中折叠边框模型的实现是否有效？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！