[css-tables] Collapsed table borders don't follow sticky rows/cells when they stick

[jan-tosovsky-cz]

Major browsers have implemented position:sticky for table headers in a way only cell are sticky, not collapsed borders, see https://jsfiddle.net/70vjwymx/ (header borders are transparent). I am not sure what should be fixed:

• my css (some additional settings)
• browser code
• specification
  I suppose position:sticky was implemented to ease styling cases like sticky table headers so I believe borders should be a part of that sticky content.

[jonjohnjohnson]

@jan-tosovsky-cz I've noticed similarly and don't think it's an issue with your css. The feature is quite underspecified, leaving browsers to implement and discover a lot. In css-position-3, it says "a stickily positioned box is positioned similarly to a relatively positioned box", which, being too simple a comparison, has caused confusion about stacking contexts and tables. Here, it's most likely piggybacking on the way that position: relative only adds the position scheme to a cells content box, leaving the collapsed borders "in flow".

There already are compatibility issues with rendering unique collapsed borders, which depend on document order, border-width, and the alpha channel of border-color, though I'm guessing you'd suggest that borders be "doubled up and stacked atop each other" visually?

[jan-tosovsky-cz]

@jonjohnjohnson thanks for explanation, that relative position influence on cell borders is weird in this context and undermines the original intent to have an elegant CSS way for making table headers sticky.

Yes, I expect copying the complete table header (cells + borders) and placing it on top of the original table. If this is out of scope of this spec, I'd be grateful for incorporating this common request into more appropriate spec.

[isat7]

working code: just add background-clip:padding-box;
`html{
padding: 0px;
margin: 0px;
}
body{
padding: 0px;
margin: 0px;
width:100%;
}

th,td{
padding:10px;
border: 0.1px solid #e8e0e0;
padding-right:10px;
}
th{
text-align: center;
background: #f3f3f3;
background-clip: padding-box;
}

thead th:first-child {
left: 0;
z-index: 1;
}
tbody th:first-child {
text-align: center;
position: -webkit-sticky; /* for Safari */
position: sticky;
left: 0;

}
tbody th,thead th:first-child {
/* display:flex; /
/ text-align: center;
align-items: center;
align-self: center; */
width:30px;

min-width: 30px;
max-width: 30px;
word-break: break-all;

}
.fixed_header{
width: 100%;
/* height: 500px; /
table-layout: fixed;
border-collapse: collapse;
}
/ .fixed_header tbody{
overflow: auto;

} */

/* fixed header /
thead th {
/ for Safari */
text-align: center;
position: -webkit-sticky;
position: sticky;

top: 0;

}

.fixed_header th, .fixed_header td {
padding:10px;
/* text-align: left; */
width: 90px;
}

.fixed_header td{
/* padding:10px; /
/ word-break: break-all; /
/ max-width: 200px; /
}
.table_container{
/ position: fixed; */
position: relative;
width:100% ;
min-height: 500px;
overflow: auto;
background:cornsilk;
}

<table class="fixed_header">
            <thead>
              <tr>
               <th></th>
                <th>Col 1</th>
                <th>Col 2</th>
                <th>Col 3</th>
                <th>Col 4</th>
                <th>Col 5</th>
                      <th>Col 1</th>
                <th>Col 2</th>
                <th>Col 3</th>
                <th>Col 4</th>
                <th>Col 5</th>
                      <th>Col 1</th>
                <th>Col 2</th>
                <th>Col 3</th>
                <th>Col 4</th>
                <th>Col 5</th>
                      <th>Col 1</th>
                <th>Col 2</th>
                <th>Col 3</th>
                <th>Col 4</th>
                <th>Col 5</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <th>1</th>
                <td>row 1-1</td>
                <td>row 1-2</td>
                <td>row 1-3</td>
                <td>row 1-4</td>
                <td>row 1-1</td>
                <td>row 1-2</td>
                <td>row 1-3</td>
                <td>row 1-4</td>
                <td>row 1-1</td>
                <td>row 1-2</td>
                <td>row 1-3</td>
                <td>row 1-4</td>
                <td>row 1-1</td>
                <td>row 1-2</td>
                <td>row 1-3</td>
                <td>row 1-4</td>
                <td>row 1-1</td>
                <td>row 1-2</td>
                <td>row 1-3</td>
                <td>row 1-4</td>  
            </tr>     

            </tbody>
          </table>
        </div>
  `

[tabatkins]

It would be great if this worked in a way that makes sense. Currently, the behavior you're seeing is working-as-intended; in the collapsed-borders model, the borders "belong to" the table, not the cells or rows. But it looks real bad, I agree. ^_^

So, this isn't really a Position issue, it's more an issue for Tables to possibly define a better model for collapsed borders that'll work with this. That's up in the air, so we'll leave this issue open, but we're not planning on addressing it in the Position spec at all.

[fantasai]

Not sure if "working-as-intended" is quite the right word here. It's "working-as-implemented", but the CSS2 spec wasn't particularly clear about how collapsed borders attach.

[atotic]

Chrome discussed what to do here in https://crbug.com/1181813

This is what happens "per 2.1 spec":

1. table paints collapsed borders in foreground phase
2. table parts that generate stacking contexts paint after table foreground paint phase. Their background paints over collapsed borders per spec.

Several browsers have tried to extend the spec to alleviate the problem of missing borders. The solution implemented is:

3. "clip background of stacking context cells to content box, therefore not hiding borders underneath". This solution has some drawbacks:

• any cells that change their position (ex: scrolled sticky) lose their borders.
• intersections of mixed size borders can be wonky, see https://jsfiddle.net/atotic/pzunko34/

The existing browsers behavior is:

Firefox: per spec, borders just get blown away
Chrome: clips (step 3) if TD/TR/TBODY generate stacking contexts.
Safari: clips TD, per spec for TR/TBODY

I believe that the most common use of table parts generating stacking context in tables will be:

1. posiition:sticky, make those header rows sticky! The clip hack is not what is desired here
2. position:relative, to contain some absolute elements. Clip hack works well for this use case.

Web developers, intuitively, believe that collapsed borders belong to cells, not to the table.

My personal opinion:
I used to believe that clip hack was good, until I saw the position:sticky bug reports.
Now I believe that we should not clip backgrounds. This would force developers to immediately notice the problem, and work around it.

It would be good to have an official resolution. position:sticky on table rows will be popular. Once Chrome ships TablesNG, it will be supported on all browsers.

[FremyCompany]

Just a small note that, while it doesn't match implementation at all, the new table spec says borders are to be painted on the cells and not the table background.

At the very least, I think it would make sense to switch to that mode when cells are forming a new stacking context.

In that scenario, cells each draw their side of the border (half of it on each side).

[atotic]

I've ran into another place where table painting of collapsed borders does not work: fragmentation.

When table is fragmented, headers/footers might be repeated on every page when table is printed.
This means that headers will share borders with multiple different tbody rows.

I call these cases "fluid grid" cases. "Table paints collapsed borders" assumes that grid is static: cell location is fixed, and table parts do not generate new stacking contexts. But, we have cells that violate these assumptions:

• position:fixed cells generate new stacking context, and change location
• fragmentation can change cell's location, and neighbor cells.
• various css properties can generate new stacking contexts.

I think there is a place in the spec for both types of painting. Painting borders by a cell cannot handle some cases:

• intersection painting of non-adjacent cell borders, see issue [css-tables-3] Make rendering of border intersections undefined for collapsed borders model #6039
• painting of column/row borders when cells do not exist. (FF's always done this, TablesNG does it now too).

I think that following would be the most powerful solution:

• paint all collapsed borders by table
• fluid cells also paint their own half-borders, like the spec specifies today.

I would like to understand how "self-painting borders" handle intersections.