Background of cell paints over border when borders are collapsed and tbody, row, or cell is relatively positioned




8 years ago
4 months ago


(Reporter: bzbarsky, Unassigned)


(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [webcompat])


(4 attachments)

Posted file Testcase
See attached testcase, which is self-describing.

Comment 1

7 years ago
Same here for Firefox 14 on Linux

Comment 2

7 years ago
Same for Firefox 16 on Windows 8

Comment 3

7 years ago
I know your test case show the problem quite well but you seem to missing some tags like a </tr>. I created another test case to describe the problem, It's only present when you use css border-collapse, if you use the old cellpadding/cellspacing Firefox render the table borders correctly. Weird :/

This is present in Firefox 16.0.2 in Ubuntu 12.04.


7 years ago
Attachment #685550 - Attachment mime type: text/plain → text/html

Comment 4

6 years ago
Same for Firefox 23 on Windows 8.
Same in 26 on Linux. Could someone please change the Platform to "all platforms"?

This bug is becoming ridiculously old and neglected. It affects many datagrid UIs that allow drag-and-drop reordering.
The basic problem is that the table painting code is unowned....

David, do you know who might be available to look into this?
Flags: needinfo?(dbaron)
OS: Mac OS X → All
Hardware: x86 → All
Seth might be interested.  I think this could serve as the bug for sorting out the z-order/painting aspects per bug 35168 comment 38.  Though fixing this might actually be massively simpler:  I suspect it will be fixed by removing the code from nsTableRowFrame and nsTableRowGroupFrame that invokes TableBackgroundPainter on rows or row groups, and removing the IsPseudoStackingContextFromStyle() checks in nsTablePainter.  That would match CSS 2.1... though I think it would also break 'opacity' on internal table parts.  That said, I don't see a consistent model that involves having 'opacity' work.  (Also, there will be issues when relatively positioning cells -- I tend to think that at least borders in the separated borders model should move with relative positioning.)

Also see bug 858333 and the resolution in .

The current spec might not be Web-compatible here, so research would be needed.  I'm also not convinced this is worth spending time on right now.
Flags: needinfo?(dbaron)
Seth noticed that Chrome and Safari have the same bug once there's an offset, but only in the part that's overlapped by the contents.
[looking into this with seth]

It seems like the difference here between Gecko and other engines (at least WebKit/Blink) is what area the background covers.  I thought the spec said that the cell background in the collapsed borders model was supposed to extend to the middle of the border (so that, e.g., a dotted border would have underneath the dots the backgrounds of the two adjacent cells, meeting in the middle), though I can't find the relevant quote from the spec right now.
Backgrounds in CSS generally paint under the border.  The tables section of CSS 2.1 doesn't specify anything contradicting that... but also doesn't explicitly say anything like comment 10.  :(
Duplicate of this bug: 995263

Comment 13

4 years ago
Will someone fix this? It affects my site very much.
The problem is that it's not clear what the correct behavior is.  The spec doesn't particularly define it, unfortunately.

Comment 15

4 years ago
I mean, just because you change position to relative, the border should not disappear. Perhaps the specification does not *explicitly* say that, but then it's the specification that's not complete. Right now it just delivers unexpected behaviour.
No, the point is the specification doesn't define what you _should_ do in this case.  Please do see the earlier comments in this bug.

And yes, the fact that the spec doesn't define it is a problem with the spec.  The right thing to do is get the spec fixed and then implement the result.

Comment 17

4 years ago
Why is the rendering different with position relative, though? Is there some interpretation of the spec that would allow just setting the cell's position to relative to affect rendering of the border?
The spec here is

In my original testcase in this bug, there is one stacking context: the one for the root element.

The borders of the table are painted in step 4 of the painting order, since the table is an in-flow, non-positioned, block-level descendant of the root.  Note that the background should also paint in step 4, per spec, but...

The tbody itself is painted in step 8, since it's positioned.  And the problem is that the "paint a tbody in a non-default z-order" code paints backgrounds too, afaict.

And the real question is what should happen if the cell is rel pos and has nonzero offsets.  Should its text move, but not its background?  Should the background move but stay painting at the same z-order it would paint at if the cell were not positioned?  Something else?

All of those questions are normally avoided for relatively positioned things by painting their backgrounds atomically with the element in step 8...

You may want to compare to this simple non-table testcase:

  <div style="background: yellow; height: 200px; margin-bottom: -50px"></div>
  <div style="border: 5px solid black; height: 100px"></div>

to this one:

  <div style="background: yellow; position: relative; height: 200px; margin-bottom: -50px"></div>
  <div style="border: 5px solid black; height: 100px"></div>

which is a clear demonstration of how position:relative can and does affect z-ordering.

Comment 19

4 years ago
Thanks for your answer, it makes sense to me now.

I still would prefer if, in the one case where the spec is unclear (position: relative and zero offsets), the browser would interpret it in the "least surprising" way. That is, same as webkit and trident.

That said, I can see how this change would not be worth the trouble, given the current ambiguity of the specification.
(In reply to Not doing reviews right now from comment #18)
> The tbody itself is painted in step 8, since it's positioned.  And the
> problem is that the "paint a tbody in a non-default z-order" code paints
> backgrounds too, afaict.

Per the cited spec I think this is clearly a bug; it should paint in step 4, and not in step 8, since nothing in step 8 leads to the painting of backgrounds on tbodies.

> And the real question is what should happen if the cell is rel pos and has
> nonzero offsets.  Should its text move, but not its background?  Should the
> background move but stay painting at the same z-order it would paint at if
> the cell were not positioned?  Something else?

Yes, this part isn't defined, but I think it's also entirely separate from this bug (and one we've already had to solve in bug 35168 -- and I think we came up with reasonable solutions to it).

It's also *explicitly* undefined in , fwiw.
Duplicate of this bug: 1185232
Chromium 43 does not have the (simpler) duplicate issue outlined in bug 1185232.

Comment 23

4 years ago
Regardless of what the spec says, I feel the current behavior is unorthodox. For "border-collapse: collapse"  the borders vanish. For "border-collapse: separate", the borders appear (but separated). Nowhere else in HTML does adding a background to an element make its border vanish, and in my opinion border-collapse should certainly not hide the border.

In Chrome, its working as I would expect as a developer who hasn't read the spec. I can simply apply a border & a background to my <td>, and both the border & background are visible.

Comment 24

3 years ago
Think back to the bad old days of late 90's and early 2000's. The problem with non-standard render behaviors isn't that they are non-standard, but because they are non-standard in different ways. That was what made developers' lives so miserable. To me, that's the biggest motivation and benefit of standardization.

Now, FF is the only browser that behaves differently than all the other browsers, which regardless of what the actual spec says, goes against the spirit of standardization for the average developer. Considering that there isn't a simple workaround for this problem, my opinion would be that the priority really should be higher.

Comment 25

3 years ago
Looks like a simple workaround is to add "background-clip: padding-box" attribute to the cell:

   position: relative;
   background-clip: padding-box;

It works in my specific case.

Actually the workaround works for my testcase in bug 1185232 too.

Comment 27

3 years ago
This workaround is not working for me.
Blocks: 1301450

Comment 28

2 years ago
We're running into problems with this behavior as well. Generally our sites have all the prerequisites for this issue to occur in our table cells:

- `border-collapse: collapse;`
- a defined border
- a background color (usually on header cells (th))

Once those rules are in place, then if, for example, you use a library like Ember Light Table, which applies `position: relative;` to `th` by default, or even just apply it manually for any other reason, your table cell borders all magically disappear, but only in Firefox.

It took me a while to find this thread, probably bad google karma, but I was tearing my hair out. fwiw, `background-clip: padding-box;` resolved the issue for us as well (which seems logical - the background doesn't extend to the borders), although so did applying the background-color to the table row (tr) instead of the individual cells - once the `background-color` rule was removed from the `th`s and `td`s the borders showed up fine.

Comment 29

2 years ago
This also appears to happen if you set the parent TR background-color. The difference is that background-clip: padding-box DOES NOT correct it.

Comment 30

2 years ago
@joel_kinzel - checked it out and you're right, if the rules above (position, border, bgcolor) are set on the table rows instead of the cells, then the table row borders disappear just like the cell borders did. However, unlike the cell borders, applying background-clip to the rows does not cause the table row borders to reappear.

Here's a codepen I made demonstrating the issue as I understand it:

Comment 31

2 years ago
(In reply to threecleartones from comment #30)

@threecleartons - illustrates it perfectly. Thanks for putting that together.

The work around for the scenario that I presented is basically don't put a background-color on the TR element, do it on the child TD elements instead.

Comment 32

2 years ago
Not sure if this is the same bug or not, but when I browse [1] *some* tables (not all) have issues with their borders. There are even some tables where the border is shown for some cells but not the others. Note that all these tables are subject to the same CSS rules.

Testing with Firefox 51.0.1 on Windows.


Comment 33

2 years ago
Sorry, got to clarify: the above issue occurs when you "zoom out" on the page only.

Comment 34

2 years ago
wow, this actually an old bug from 6 years ago.

I just leave and example then

as to why i need to layout my table like that, its to places absolute positioned elements in the table cells like icons etc.

Comment 35

2 years ago
Another thing I found out is that when you use @threecleartons example, but use multiple tbody's, it stops working when you add an empty <tbody></tbody> somewhere, please see for example

Comment 36

2 years ago
I'm having a problem with table thead th element borders (rather than the borders of cells within the table tbody) but the problem is the same - the borders of adjoining th elements, and the bottom borders of those same elements, do not appear when the th elements have a background property set.


Or, as images, first in Firefox 52.0.2, second Google Chrome:

Comment 37

2 years ago
Same bug in 56.0b9 (64 bits)
Blocks: 1379038
Duplicate of this bug: 1379038
Priority: -- → P3
Whiteboard: [webcompat]
You need to log in before you can comment on or make changes to this bug.