RE: [css-tables] border-collapsing rule is wrong

> I don't think this is fixable, but I just wanted to note that rule #4 in
>    https://www.w3.org/TR/CSS2/tables.html#border-conflict-resolution
> is designed backwards. The table should win over the col/rowgroup which
> should win over the row/col which should win over the cell.
> 
> The common use case for this is darker borders on rowgroups vs. lighter ones
> on cells. The rowgroup borders are more important, even though they are
> less specific.

Thanks for looking into this. As you know, we would like the spec to codify as much as possible what browsers currently do. To modify such a behavior, we would have to prove the change is really for the better and its impact is really small. I think your proposal makes sense, but I have no idea whether we could fix it without breaking the web or not.

That being said, the default styling of a border table is "outset" which wins over the "inset" style defined for cells, which incorrectly lead me to have the current spec change this behavior to: table > cell > track > track-group (see the order of the two bold paragraphs here: https://drafts.csswg.org/css-tables-3/#border-conflict-resolution-algorithm). This is of course inaccurate, Greg and I are going to modify this back to the original behavior defined in CSS 2.1 (that is, invert the order of the two bold paragraphs). 

On a more general note, my current thinking is that -- by default -- the burden of proving a change is web compatible should be put on the person requesting the change, and not to the spec editors. If you want us to consider this change, I would encourage you to provide data showing changing this behavior would not affect (m)any website(s), or find a volunteer among the other group members that is willing to conduce this analysis. Please note that browsers are not entirely interoperable on a test case I just wrote to dig into this deeper regarding rows and cells, probably because of a default border-width and bugs (which may help change this behavior, since authors are not expected to rely on non-interoperable behaviors).

Kindly yours,
Francois

Received on Monday, 15 February 2016 08:28:07 UTC