Closed Bug 6990 Opened 25 years ago Closed 25 years ago

Table Headings run together

Categories

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

Product:
Core
Component:
Layout: Tables
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 6247

People

(Reporter: sdennett, Assigned: karnaze)

References

(
URL
)

Details

On the table on this page, the heading for column 4 is displayed in the cell for the column 3. The result is that the heading for column 5 is moved over column 4, giving the mistaken impression that the prices listed under that heading are the prices for those dates. The headings for columns 3 - 5 should be: Column 3: 22/5 - 16/07 Column 4: 28/8 - 01/10 Column 5: 17/07 - 27/8
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Just some really creative HTML ;) For the problem reported, it turns out to be a 4.5 compatibility thing that rickg did fix in the past couple of weeks (but didn't give TH the same 'free pass' as TD). Marking duplicate of bug #6247 for the reported problem (and ignoring some others because they break 4.5 as well). *** This bug has been marked as a duplicate of 6247 ***
This is an isolated case of the area in question: <html> <head> <title>6990</title> </head> <body> <table align="center" cellspacing=0 cellpadding=5 border=1> <tr> <th align="center"nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">"99 Rates in Drahmas Per Person on H/B Basis</font> </tr> &nbsp; </th> <th align="center" nowrap bgcolor="#EEEEEE"> <font size="2" color="#000000">27/03 - 30/04 </font><br><font size=-1 color="#000000">16/10 - 31/10 </font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">01/5- 21/5 & 2/10 - 15/10</font> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">22/5 - 16/07</font><br><font size=-1 color="#000000">28/8 - 01/10</font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">17/07 - 27/8</font> </tr> </table> </body> </html> One problem I see is that the first row is closed out before the end </th> tag. It looks like the parser is ignoring the </th> tag and assumes a new row with the next <th> tag. If this is so, Gecko is displaying the table correctly. I tested on Mac8.5 and Win 95 using 5/24 Apprunner. If this is the case, the bug probably isn't a duplicate but invalid. Please review and mark as appropriate.
This is an isolated case of the area in question: <html> <head> <title>6990</title> </head> <body> <table align="center" cellspacing=0 cellpadding=5 border=1> <tr> <th align="center"nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">"99 Rates in Drahmas Per Person on H/B Basis</font> </tr> &nbsp; </th> <th align="center" nowrap bgcolor="#EEEEEE"> <font size="2" color="#000000">27/03 - 30/04 </font><br><font size=-1 color="#000000">16/10 - 31/10 </font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">01/5- 21/5 & 2/10 - 15/10</font> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">22/5 - 16/07</font><br><font size=-1 color="#000000">28/8 - 01/10</font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">17/07 - 27/8</font> </tr> </table> </body> </html> One problem I see is that the first row is closed out before the end </th> tag. It looks like the parser is ignoring the </th> tag and assumes a new row with the next <th> tag. If this is so, Gecko is displaying the table correctly. I tested on Mac8.5 and Win 95 using 5/24 Apprunner. If this is the case, the bug probably isn't a duplicate but invalid. Please review and mark as appropriate.
This is an isolated case of the area in question: <html> <head> <title>6990</title> </head> <body> <table align="center" cellspacing=0 cellpadding=5 border=1> <tr> <th align="center"nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">"99 Rates in Drahmas Per Person on H/B Basis</font> </tr> &nbsp; </th> <th align="center" nowrap bgcolor="#EEEEEE"> <font size="2" color="#000000">27/03 - 30/04 </font><br><font size=-1 color="#000000">16/10 - 31/10 </font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">01/5- 21/5 & 2/10 - 15/10</font> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">22/5 - 16/07</font><br><font size=-1 color="#000000">28/8 - 01/10</font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">17/07 - 27/8</font> </tr> </table> </body> </html> One problem I see is that the first row is closed out before the end </th> tag. It looks like the parser is ignoring the </th> tag and assumes a new row with the next <th> tag. If this is so, Gecko is displaying the table correctly. I tested on Mac8.5 and Win 95 using 5/24 Apprunner. If this is the case, the bug probably isn't a duplicate but invalid. Please review and mark as appropriate.
This is an isolated case of the area in question: <html> <head> <title>6990</title> </head> <body> <table align="center" cellspacing=0 cellpadding=5 border=1> <tr> <th align="center"nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">"99 Rates in Drahmas Per Person on H/B Basis</font> </tr> &nbsp; </th> <th align="center" nowrap bgcolor="#EEEEEE"> <font size="2" color="#000000">27/03 - 30/04 </font><br><font size=-1 color="#000000">16/10 - 31/10 </font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">01/5- 21/5 & 2/10 - 15/10</font> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">22/5 - 16/07</font><br><font size=-1 color="#000000">28/8 - 01/10</font> </th> <th align="center" nowrap bgcolor="#EEEEEE"><font size="2" color="#000000">17/07 - 27/8</font> </tr> </table> </body> </html> One problem I see is that the first row is closed out before the end </th> tag. It looks like the parser is ignoring the </th> tag and assumes a new row with the next <th> tag. If this is so, Gecko is displaying the table correctly. I tested on Mac8.5 and Win 95 using 5/24 Apprunner. If this is the case, the bug probably isn't a duplicate but invalid. Please review and mark as appropriate.
Whiteboard: Pending response - see 5/24 comments
I agree, even in quadruplicate :). Gecko is doing the correct thing here, but, of course, compatibility is also a goal. Given: this bug (TH) or bug #6247 (TD) (paraphrased) <table border> <table border> <tr> <tr> <th> foo </TR> </th> <td> bar </td> <th> bar </th> <td> foo </TR> <th> baz </th> <td> baz </td> </tr> </tr> </table> </table> The correct thing is to close the row, and open another on the following TD|TH. I was surprised that 4.5 did *not* do this. rickg said 'Egad', but decided to fix it. This is, of course, a situation where one might want to break compatibility: what if 'two rows' is what the author intended? However, given that rickg had FIXED this for TD, then I marked this as DUPL and REOPENED bug #6247 noting that the handling of TD and TH were now inconsistent in this respect. This, I thought, would tend to keep the same issue on the same bug report. Sorry if I was wrong. Perhaps though the fix for 6247 is something that either you or ChrisK wants to reconsider with rickg. ((Final note FWIW: IE5 has the same 'behaviour' as Nav4.5))
Status: RESOLVED → VERIFIED
Whiteboard: Pending response - see 5/24 comments
Yes, I see your point. Verifying bug a duplicate of #6247
Responding to the email from sdennett@aol.com: Sorry. When I wrote "... IE5 has the same 'behaviour' as Nav4.5" what I meant was that it did not terminate a row on </TR> either. That bug/compatibility issue is, in fact, already fixed (see bug #6247) So, if I patch the HTML to workaround that '</TR>' bug (emulate the fix) then I can see that Mozilla easily lays ... oh, crap ... no it doesn't. It looks fine at ~800px width, but if shrink the window, the table is clipped on the right side instead of uhh "flexed" (?? sorry, easy to see, hard to explain ). Thanks for pointing this out. I will look at this with tomorrow's build and file a new bug (cause this one is way too long for one day now ;) [By the way: you can see a small flaw in the GIF that you sent -- blue borders (at top of image) are not equal -- they should be -- likely the same root cause.]
You need to log in before you can comment on or make changes to this bug.