- From: Francois Remy <francois.remy.dev@outlook.com>
- Date: Fri, 19 Feb 2016 12:08:24 -0800
- 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