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

Status: NEW

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

Description

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

See attached testcase, which is self-describing.

Comment 1

[Tim Fuchs]

Same here for Firefox 14 on Linux

Comment 2

[gleb.svechnikov]

Same for Firefox 16 on Windows 8

Comment 3

[sombra2eternity]

Attachment: table border behaviour

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.

Comment 4

[Doug Lorch]

Same for Firefox 23 on Windows 8.

Comment 5

[Szczepan Hołyszewski]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The basic problem is that the table painting code is unowned....

David, do you know who might be available to look into this?

Comment 7

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

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.

Comment 8

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

Attachment: testcase with relative positioning on the cell rather than tbody

Comment 9

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

Attachment: testcase with relative positioning on the cell, and offsets

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.

Comment 10

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

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[gustav.ekner]

Will someone fix this? It affects my site very much.

Comment 14

[Boris Zbarsky [:bzbarsky]]

The problem is that it's not clear what the correct behavior is.  The spec doesn't particularly define it, unfortunately.

Comment 15

[gustav.ekner]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

[Petr Certik]

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?

Comment 18

[Boris Zbarsky [:bzbarsky]]

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.

Comment 19

[Petr Certik]

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.

Comment 20

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

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

Comment 22

[Julien Wajsberg [:julienw]]

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

Comment 23

[josh.ribakoff]

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

[waynebeast]

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

[Toub]

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

Comment 26

[Julien Wajsberg [:julienw]]

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

Comment 27

[David]

This workaround is not working for me.

Comment 28

[threecleartones]

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

[joel_kinzel]

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

[threecleartones]

@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

Comment 31

[joel_kinzel]

(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

[Huji]

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

Comment 33

[Huji]

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

Comment 34

[am05mhz]

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.

Comment 35

[mischamolhoek]

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

Comment 36

[Mike]

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

Comment 37

[ALAMI]

Same bug in 56.0b9 (64 bits)

Comment 39

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 40

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 41

[gleb.svechnikov]

Bug still reproducible in Firefox 72.0.1 on Linux

Comment 42

[piotrusci]

Bug still reproducible in Firefox 81.0 on Windows 10

Comment 43

[Geoffrey Crofte]

Bug still reproducible in Firefox 81.0.1 on Mac.
I personally use background-clip: padding-box; to solve this, but I suppose it still a bug.
https://codepen.io/GeoffreyCrofte/pen/WNxMBXg

Comment 44

[marianna.shvartsapel]

Just spent hours debugging this weird behavior! Please prioritize fixing this old bug.

Comment 45

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates, 23 votes and 5 See Also bugs.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 46

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 47

[chenxeed]

Hi, this issue still happened on my Firefox browser 107.0.1 (64-bit).

(In reply to Geoffrey Crofte from comment #43)

Bug still reproducible in Firefox 81.0.1 on Mac.
I personally use background-clip: padding-box; to solve this, but I suppose it still a bug.
https://codepen.io/GeoffreyCrofte/pen/WNxMBXg

This solution works for me.

Comment 48

[sergchernata]

This is still an issue in 114.0.2 (64-bit) when using :nth-of-type(odd) selector.

Comment 49

[Rafał Miłecki]

CSS 2.1 indeed says: "The effect of 'position:relative' on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined."

What about CSS 3 though? I checked:
https://www.w3.org/TR/css-position-3/#valdef-position-relative
and
https://www.w3.org/TR/css-position-3/#relpos-insets
but I don't see relevant info about undefined behaviour. Is that sill the case?

Comment 50

[Dennis Schubert [:denschub]]

None of the non-testcase examples still show issues as they've changed, so we don't have active WebCompat breakage to track here.