Is the collapsing border model's implementation in web browsers valid? - html

Question

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:

Answer 1

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.