Closed Bug 10036 Opened 21 years ago Closed 20 years ago

[BLOCK] cells with <br> alone considered empty

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: endico, Assigned: buster)

References

()

Details

(Keywords: css1, testcase, Whiteboard: [testcase] (py8ieh:eviltests fodder))

Attachments

(3 files)

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.
Attached file test case
Assignee: troy → karnaze
Component: Layout → HTMLTables
Summary: background color of empty table cell is not set → {compat} background color of empty table cell is not set
Whiteboard: [testcase]
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.
Status: NEW → ASSIGNED
Target Milestone: M11
*** Bug 12365 has been marked as a duplicate of this bug. ***
Summary: {compat} background color of empty table cell is not set → {compat} cells with <br> alone considered empty
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.
Assignee: karnaze → kipp
Status: ASSIGNED → NEW
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
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Fixed. The test now renders compatibly.
*** Bug 13613 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
Fixed in the Sept 13th build.
Status: VERIFIED → REOPENED
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.
Status: REOPENED → ASSIGNED
Target Milestone: M11 → M15
Resolution: FIXED → ---
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...)
Attached file sample
It should definitely be taller.  However, it's not clear whether the content
that makes it taller is "visible content".
Summary: {compat} cells with <br> alone considered empty → {css} cells with <br> alone considered empty
Severity: normal → trivial
Target Milestone: M15 → M20
Changed summary to indicate that this is a css1 issue, not a compatability issue
since the compatability issue has been fixed.
Summary: {css} cells with <br> alone considered empty → {css1} cells with <br> alone considered empty
Whiteboard: [testcase] → [testcase] (py8ieh:eviltests fodder)
QA Contact: petersen → chrisd
Updating to default HTML Tables Assignee...kipp no longer with us :-(
Assignee: kipp → troy
Trying again ...assigning to troy.
Assignee: troy → kipp
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...
Summary: {css1} cells with <br> alone considered empty → {css1} [BLOCK] cells with <br> alone considered empty
Keywords: css1
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!
Keywords: testcase
Summary: {css1} [BLOCK] cells with <br> alone considered empty → [BLOCK] cells with <br> alone considered empty
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!
Assignee: kipp → buster
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M20 → M22
I believe this has been fixed for a while now.
Status: NEW → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → FIXED
Verified.
Windows: 2000-07-13-09-M17
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
Target Milestone: --- → Future
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.