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
> >
> > 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:
> 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

Issue added:

Received on Friday, 19 February 2016 20:08:55 UTC