This is a case where mozilla 5.0 works differently than my 4.6 browser. I'm not sure what the html spec says the correct behaviour should be. At the bottom of the screen on either side of the copyright notice the table cells aren't being set to black. The cells are empty except for a <BR>. It would be nice if empty table cells had the background color set but since they don't (even in 4.x), the <BR> was put there as a place holder. 4.x renders this page with a black border along the bottom but 5.0 does not.

Mozilla is correct as per the CSS2 spec. From CSS2 17.5.1: Table cells without visible content are invisible: "These 'empty' cells are transparent, letting lower layers shine through." From 17.6.1: "Visible content includes "&nbsp;" and other whitespace except ASCII CR ("\0D"), LF ("\0A"), tab ("\09"), and space ("\20")." The <br> element in HTML is equilvalent to a linefeed (br:after {content:"\A;"}), so it doesn't fall under "visible content." --- endico@mozilla.org: You can easily work around this on mozilla.org by replacing the <br> with a "&nbsp;". --- I won't mark this bug invalid because it may (and probably should) become a compatibility quirk. Marking [testcase]--there should be a pink cell on the table in compatibility mode.

See bug #8113. This one is effectively a dup except that this report does note the 'grandfather' status of empty elements triggering background color (i.e., <BR>, <SPACER>, others?) --- there's another bug floating around somewhere that also mentions this behaviour, but I can't see it at the moment.

*** Bug 12365 has been marked as a duplicate of this bug. ***

Changing summary from "background color of empty table cell is not set" to "cells with <br> alone considered empty" becuse this is what this bug is really about. The issue of truly empty cells, is in bug 8113 as 3jrgm pointed out. (It's now marked REMIND.) Adding dbaron (from bug 12365) and myself to the CC: list.

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1363 is a good test case that I wrote for bug 12365. From reading what's on this bug, I guess it should be a quirk...

Last week I noticed a difference between apprunner and viewer in what they consider a blank cell. At on the bottom of http://www.mozilla.org/ the copyright notice is in a table row with several columns. Each column is virtually empty except the one with the copyright notice. Apprunner paints the entire row black (as intended) but viewer does not. This surprised me since I thought they should behave the same. Viewer renders the other parts of the table that I had previously had trouble with ok. I was going to investigate further but I haven't had a chance yet. I thought it was worth noting here because of the difference between apprunner and viewer.

Re: endico's comment Just checked with 1999-08-23-16 on WinNT 4sp3 Apprunner and Viewer works the same for me. It's the behaviour as you describe it for the viewer.

Kipp, the cell considers its content to be empty if the max element width of its area frame is 0, which is the case here. Could the <BR> be made to have a non zero max element/desired width.

See also bug 8873 for this issue as it relates to <spacer> elements

Fixed. The test now renders compatibly.

*** Bug 13613 has been marked as a duplicate of this bug. ***

Fixed in the Sept 13th build.

Cells with <br> alone should considered empty ONLY in quirks mode. But even if in standard mode, there are pink cell on the table (see the test case). I'm using [1999102110] build mozilla and viewer. Reopening.

Somebody needs to explain to me why what you believe about the BR behavior in the table cell is "right". Because I don't agree. If I don't here a convincing argument (dbaron are you listening?) then I'm going to close the bug. Given that there are no colspan/rowspan tricks going on in the test table, there *should* be a pink cell because the cell will be sized to match its neighbors.

The argument is given by bloviate@yahoo.com in the third comment on this bug. I believe his argument is correct, but I'm not 100% sure myself: I'm not sure if the spec should have said (although it didn't!) that an element counts as content. However, I think in standard mode, <td><span></span></td> should definitely behave the same as <td><br></td> (in terms of whether the cell is considered empty).

In standard mode, <td><br></td> seems to be slightly taller than <td></td>. Is it incorrect? (I'm not sure...)

It should definitely be taller. However, it's not clear whether the content that makes it taller is "visible content".

Changed summary to indicate that this is a css1 issue, not a compatability issue since the compatability issue has been fixed.

Updating to default HTML Tables Assignee...kipp no longer with us :-(

Trying again ...assigning to troy.

STOP IT! Stop re-assigning Kipp's bugs. They are that way for a reason, and you have absolutely no business touching Kipp's bugs or any layout bugs...

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

This bug looks fixed in win32 is this a Linux only bug? Can someone check?

Table cells containing nothing but <br> are painted with the background color for me on linux. Looks like this bug is fixed. Reassigning to default component owner so a real human can close this bug. (formerly owned by the pseudo- user kipp)

mine! mine mine mine! all mine! whoo-hoo!

redistributing bugs across future milestones, sorry for the spam

I believe this has been fixed for a while now.

Verified. Windows: 2000-07-13-09-M17