table borders don't draw correctly

VERIFIED DUPLICATE of bug 25228

Status

()

defect
P3
major
VERIFIED DUPLICATE of bug 25228
20 years ago
19 years ago

People

(Reporter: jlevine, Assigned: attinasi)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
There are a few tables or table elements on the page that don't get the borders 
that they should be getting.

First, there's the MEMBERSHIP table in the left-hand bar, which should have a 
single border around it; instead, it has a double-border at the right and 
bottom.

Second, there's the bookmarks table below that, on the left; the cell that 
reads "bookmarks" should have a solid, thin, black line bordering its bottom 
margin, but nothing draws in for that border.

Lastly, and similarly, there's the bottom line of the page (the copyright 
line), which should have a thin, black, solid border along its TOP margin; 
nothing draws in for that, either.
The first problem is a duplicate of bug 22897.  I suspect the latter two are
duplicates of bug 2436, although more investigation is required.  The
border-collapsing rules are not yet correctly implemented.  There are enough
problems with them that it's hard to tell what's going on.
(Assignee)

Comment 2

19 years ago
I'm taking this one since it is Table-related and I am geographically nearer to 
the table-dude, karnaze.
Assignee: pierre → attinasi
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Target Milestone: M16
(Assignee)

Comment 3

19 years ago
Several problems here: dbaron mentioned that the first is a known problem with 
border-collapse, and changing the border-collapse to separate in the 
stylesheet fixes those know issues.

The problem with the calendar not showing borders between the cells that make up 
the days is due to the BORDER=0 HTML attribute on the table. I think that is 
incorrect behavior because the HTML attributes should come first in the cascade 
and have a specificity of 0 (CSS2 spec, 6.4.4). This is also the cause of the 
missing line under the Bookmarks heading.

The last problem mentioned in the original report, the missing line at the 
bottom of the page, is due to malformed HTML. The last table has no <table> tag: 
adding one fixes that problem (there are also some residual end-tags in there 
that should be removed).

Summary: changing border-colapse to separate in the stylesheet, fixing the 
malformed HTML at the end of the document, and removing the BORDER=0 HTML 
attributes from the TABLE elements fixes this page. 

I think the only Mozilla bug here is that BORDER=0 on a table should be 
overridden by an author's style rules. I'm checking to see if there is already a 
bug on that.
(Assignee)

Comment 4

19 years ago
Yep, there is a bug already: bug 25228

I'm marking this a dup as that is the only remaining bug I see here. 

Thanks for reporting these issues. Your site, although overly critical of 
Mozilla's CSS implementation IMO, is an excellent testbed for us and we will 
continue to test against it as we flesh-ou the CSS2 implementation and fix bugs.

*** This bug has been marked as a duplicate of 25228 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 5

19 years ago
Wait -- I actually consider the border-collapse problem to still be a bug; if I 
am misunderstanding, please let me know.

Essentially: I don't *want* the border-collapse style to be separate; I want it 
to be collapse.  As I understand the comments by attinasi, I am being asked to 
implement a different border-collapse model, and this isn't right -- I want 
adjacent cells' borders to collapse with each other, not stay separate.

As for the HTML BORDER=0, I agree that it's a problem with the rules in the 
rendering engine, and I'm glad that there's already a bug on this.  For 
background, I have the BORDER=0 in the HTML table definition because of some 
browsers' preference for throwing a dropshaded border when this is NOT present, 
and for me, no border is preferable to the dropshadowed border.

And as for the malformed table: I'm looking into that.

Due to the border-collapse issue, I've marked this as reopened; please let me 
know if this is inappropriate (and if I am misunderstanding your comments on 
border-collapse).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 6

19 years ago
You are correct, the border-collapse issue *is* a bug, but it is already filed 
as bug 22897. I don't want you to change your page, I was just pointing out that 
it fixes some of the problems (as workarounds) - but to be sure, the 
border-collapse problem is a bug and we will fix it.

I marked this a dup of 25228 since you can only mark as a dup of one bug, and 
dbaron had already mentioned that the border-collapse was a dup of 25228.

*** This bug has been marked as a duplicate of 25228 ***
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 7

19 years ago
I just trawled the HTML, and ran it through two HTML checkers (one internal, 
one on the web at http://www.cen.uiuc.edu/cgi-bin/weblint), and there are no 
malformed tables in the document.  This means that the third issue is still 
open.  (I wonder why, when you added a table close tag, the line showed up; 
strange.)

By my count, there are eight tables on the page, all of which have open and 
close tags.  I also see no residual end-tags on the page; I ended up building 
an outline of the page that allowed all tags with open/close versions to be 
collapsed, and everything that should have a close tag does have one, and all 
close tags match up with open tags.

Again, if I am incorrect, please let me know.  Otherwise, the bug related to 
the line across the top of the last line on the page still exists.  (Again, I 
marked this as reopened, but now on THIS issue; sorry about the flip-floppage!)

And I understand on the border-collapse issue -- I apologize for my 
misunderstanding.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 8

19 years ago
I put my text outline version of the entire page (everything between the BODY 
tags) onto my webserver, if you want to grab it -- it's at:

http://www.queso.com/qhtml.txt

It's formatted with tabs to show the entire document structure.  Searching 
for "table" in the document gives 19 total references:

- 8 table open tags
- 8 table close tags
- 3 uses of the word "table" in text
(Assignee)

Comment 9

19 years ago
I cannot find any malformed HTML, my mistakes, I'm sorry. 

I think the page has changed - the one I copied earlier had some comments at the 
end too, but I have deleted that copy... Anyway, it is a moot point because with 
the current page (I just got a new copy) the bottom line shows up when I just 
remove all of the BORDER="0" attributes from the tables. 

Again, I am not suggesting you change your page; I am merely pointing out that 
the known bug (25228) with BORDER="0" blocking the borders on TD elements is the 
cause of the problems.

I'll let you mark it as a dup this time... if you agree ;)
(Reporter)

Comment 10

19 years ago

*** This bug has been marked as a duplicate of 25228 ***
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE

Comment 11

19 years ago
verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.