See attached testcase, which is self-describing.

Same here for Firefox 14 on Linux

Same for Firefox 16 on Windows 8

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.

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?

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 http://lists.w3.org/Archives/Public/www-style/2013Jul/0081.html . 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.

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. :(

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.

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.

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 http://www.w3.org/TR/CSS21/zindex.html#painting-order 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.

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 http://dev.w3.org/csswg/css2/visuren.html#propdef-position , fwiw.

Chromium 43 does not have the (simpler) duplicate issue outlined in bug 1185232.

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.

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.

Looks like a simple workaround is to add "background-clip: padding-box" attribute to the cell: td{ position: relative; background-clip: padding-box; } It works in my specific case. Source: http://stackoverflow.com/a/16337203/1097926

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

This workaround is not working for me.

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.

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.

@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: http://codepen.io/threecleartones/pen/ObaeRQ

(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.

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. [1] https://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%A9%DB%8C%E2%80%8C%D9%BE%D8%AF%DB%8C%D8%A7:%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4_%D8%AF%DB%8C%D8%AA%D8%A7%D8%A8%DB%8C%D8%B3

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

wow, this actually an old bug from 6 years ago. I just leave and example then https://jsfiddle.net/hyr9vuyj/2/ https://jsfiddle.net/hyr9vuyj/3/ as to why i need to layout my table like that, its to places absolute positioned elements in the table cells like icons etc.

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 http://codepen.io/mmolhoek/pen/PpyvoM for example

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. See: https://jsfiddle.net/sbwmikael/45Lpde3w/6/ Or, as images, first in Firefox 52.0.2, second Google Chrome: https://pictr.com/images/2017/04/11/xDhzn.jpg https://pictr.com/images/2017/04/11/xDnAB.jpg

Same bug in 56.0b9 (64 bits)