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.

I'm taking this one since it is Table-related and I am geographically nearer to the table-dude, karnaze.

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.

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 ***

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

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 ***

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.

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

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 ;)

*** This bug has been marked as a duplicate of 25228 ***

verifying