Closed Bug 1302 Opened 26 years ago Closed 25 years ago

Over-specified/competing colspan counts break tables

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: danny, Assigned: karnaze)

References

(
URL
)

Details

(Whiteboard: [TESTCASE] 3jrgm: need to normalize colspan counts in tables)

Attachments

(2 files)

(yet another example); refer to bug #6304 for details
2.06 KB, text/html
Details
testcase; over-specified colspans break table layout
3.21 KB, text/html
Details 
Text spilled out into wrong column. Although it could just be hubristically bad
HTML from the WebMonkey guys.
Assignee: kipp → buster
Status: NEW → ASSIGNED
Assignee: buster → kipp
Status: ASSIGNED → NEW
looks like a floater problem?
Status: NEW → ASSIGNED
Summary: minor table snafu on this page when viewed using NGViewer → minor table snafu on this page -- over-specified colspans
This is a table colspan counting problem (IMHO).
The oversize <TABLE> has two rows: one has *two* <TD>
"requesting" total of 3 columns to span; second row has *one* <TD>
"requesting" total of 3 columns to span. In other words, it's asking
for one more column than the max number of 'real' elements in a row.
So, not correct HTML, but something that will occur often enough.

[There's a second problem with the table even if you clean up the
colspan arguments but I think that problem is covered in #1623]


Here's the simple case (first one shows the problem; the other adjusts the
colspan values and it works) (Dec 19 Nightly Win 95):

<html><head></head><body>
<TABLE CELLPADDING="3" CELLSPACING="0" border="1" width="400">
  <TR>
    <TD colspan="2"><P><b>This is colspan=2</b></P></TD>
    <TD>Blah Blah Blah Blah Blah Blah</TD>
  </TR>
  <TR>
    <TD colspan="3">
      <p><b>This is colspan=3</b> blah blah blah blah blah
         blah blah blah blah blah blah blah blah blah blah
      </p>
    </TD>
 </TR>
</TABLE>
<br><br>
<TABLE CELLPADDING="3" CELLSPACING="0" border="1" width="400">
  <TR>
    <TD><P><b>no colspan declared</b></P></TD>
    <TD>Blah Blah Blah Blah Blah Blah</TD>
  </TR>
  <TR>
    <TD colspan="2">
      <p><b>This is colspan=2</b> blah blah blah blah blah
         blah blah blah blah blah blah blah blah blah blah
      </p>
    </TD>
 </TR>
</TABLE>
</body></html>
Assignee: kipp → karnaze
Status: ASSIGNED → NEW
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Status: NEW → ASSIGNED
*** Bug 1788 has been marked as a duplicate of this bug. ***
*** Bug 2645 has been marked as a duplicate of this bug. ***
Here's the test case from bug #2645.

This test case (below) is derived from home.netscape.com (although
not much is left).  This is the table structure for "Autos ... Local
..." and the right-hand column ("ABCNews.com...").

 The basic problem is "competing colspan requests". The table's has two rows,
both of which have COLSPAN requests. They are both asking for one more column
than the max number of 'real' elements in either row. This seems to confuse the
algorithm. ;)

------------------------------------------------------------
<HTML><HEAD></HEAD><BODY><CENTER>

<TABLE WIDTH=600 border>

  <TR>
    <TD WIDTH=400 COLSPAN=2>         this </TD>
    <TD WIDTH=2   BGCOLOR="#99cccc"> blue </TD>
    <TD WIDTH=198>                   that </TD>
  </TR>
  <TR>
    <TD COLSPAN=4 BGCOLOR="#99cccc"> blue </TD>
  </TR></TABLE>

</CENTER></BODY></HTML>
------------------------------------------------------------
QA Contact: 4144 → 4110
Target Milestone: M6
Moving to M6.
Moving to M8.
Summary: minor table snafu on this page -- over-specified colspans → Over-specified/competing colspan counts break tables
Whiteboard: [TESTCASE] 3jrgm: need to normalize colspan counts in tables
Moving to M9.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed mostly with 7/28 changes. Please wait for a 8/4 build to verify, since I
have some additonal changes to check in.
Hey ChrisK! Looks great!

Uhh, in case I don't get back here (I've been less active in the summer heat),
Chrisd: test case ?attach_id=495 and ?attach_id=165 cover the problem -- if
they are not clear on what to look for (and re-reading, they are more than a
little unclear ;) send me email, and I'll elaborate. (Or -- fire up a pre-Jul28
build and the difference is night and day -- no words required!). John.
Status: RESOLVED → VERIFIED
Using 8/5 Apprunner, verified bug fixed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: