1450584 - Border of sticky or relative positionned table elements remains attached to main table when border-collapse:collapse is set.

Status: UNCONFIRMED

(Core :: Layout: Tables, defect, P3)

Description

[Felix Hopmann [:fehop]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

- Applying `border-collapse: collapse` to a table and `position: relative` or `sticky` and a border to some of its components (e.g. the `<thead>`), in FF59.0.2 on Win10.
https://jsfiddle.net/_xlf/L71u84e0/2/

```css
table{
  border-collapse: collapse;
}
thead{
  position: sticky;
  top: 0px;
}
th{
  border: 1px solid black;
}
```

- Additionally applying a background to these elements.
https://jsfiddle.net/_xlf/kcd8ab5d/2/


Actual results:

- The border of the cells remains where it would have been without the extra positioning.
- Backgrounds are drawn over the borders, covering them up.

This might be because those positioned elements create a new layer in rendering, which the borders are not part of.

This also happens in Edge, btw. (Even though it does not support `position:sticky` on tables)


Expected results:

Border shold be part of the positioned element, like when `border-collapse: separate` is set. (see https://jsfiddle.net/_xlf/4m4x8shp/5/  and https://jsfiddle.net/_xlf/4290whhe/1/ , last one with background)

Comment 1

[Felix Hopmann [:fehop]]

the "new layer"-assumption is due to the backgrounds beeing rendered above.
also, maybe the term "display item" is more appropriate.
(idk, I'm new to this)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

With border-collapse, I tend to think the borders *should* stay attached to the table.

Comment 3

[Felix Hopmann [:fehop]]

(In reply to David Baron :dbaron: ⌚️UTC-7 (mostly unavailable April 2-20) from comment #2)
> With border-collapse, I tend to think the borders *should* stay attached to
> the table.

I get your point for the case if I was re-positioning just a single cell, however, here I'm making the whole `<thead>` sticky. There I'd still expect to have borders (like in office table calculation programs), especially as you need to have a background-color on the <thead> to ensure readability, which (now) in turn "erases" the borders.

Comment 4

[Gérard Talbot]

I have created bug 1450601 for 1 isolated aspect of the tests in here.

Comment 5

[Flaburgan]

Tables with a sticky header is very common, I'm surprised more people didn't complain about this. I'm impacted and would love to see that fixed.

Comment 6

[Markus Szumovski]

Just found out this problem still exists. This is a five year old bug, how has that not been fixed yet?

Comment 7

[philippemp11]

I’m facing the same issue and it would be great to have it fixed. So far I implemented a work-around with border-collapse:separate but it creates more problems than it solves.
I also tested with Edge (Version 105.0.1343.53, 64-bit) and, if I remember well, the behavior was the same than with FireFox before as now the borders look to be transparent.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

So I tend to thing comment 2 is true, though chromium browsers seem to also paint the border of the sticky table cell, and I think that's a sensible thing to do given that creates its own stacking context...

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Actually that's not right. Chrome is just doing something weird with the painting order, and I can't quite get what...