W3C home > Mailing lists > Public > www-style@w3.org > February 2016

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

From: Francois Remy <francois.remy.dev@outlook.com>
Date: Fri, 19 Feb 2016 12:08:24 -0800
Message-ID: <DUB408-EAS202533C53D5DE566765B8C3A5A00@phx.gbl>
To: "'fantasai'" <fantasai.lists@inkedblade.net>, <www-style@w3.org>
> > 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
> 

Issue added:
https://drafts.csswg.org/css-tables-3/#border-style-harmonization-algorithm
Received on Friday, 19 February 2016 20:08:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC