Closed
Bug 1067
Opened 26 years ago
Closed 26 years ago
layout wrong - wrong handling of badly nested table tags
Categories
(Core :: Layout: Tables, defect, P2)
Tracking
()
VERIFIED
WORKSFORME
M9
People
(Reporter: buster, Assigned: karnaze)
References
()
Details
this used to be a floating image problem, but we think floaters are returning
correct info now. so take a look at it
Assignee: buster → kipp
Status: ASSIGNED → NEW
Component: HTMLTables → Layout
definately still a floater problem. Look at the test case below. It doesn't
involve tables at all.
The first section of the test case is left in for reference, it seems to
be doing the right thing.
Resize the window with this doc loaded, and you'll notice when the window is a
bit wider than the multi-colored rule, the image in the second section starts
jumping around wildly, and the line breaking of "Sony Signatures Website" seems
wrong. As you grow and shrink the window, the floater jumps back and forth
horizontally.
I don't know what happened, but tables regressed again...This page was laying
out (table wise) correctly and now it doesn't. I've appended to this note a
simple reduced test case that demonstrates that the first table cell is too
narrow. Note that the floater placement issues have already been fixed, so the
remainder of the test page looks correct.
--CUT HERE--
<HTML>
<HEAD>
<TITLE>Sony Computer Entertainment America Inc.</TITLE>
</HEAD>
<body bgcolor = "#FFFFFF" background="ruler.gif" LINK="#0000FF" ALINK="#FF3300"
VLINK="#FF0000">
<TABLE CELLSPACING=0 CELLPADDING=10 BORDER=0 WIDTH=0>
<TABLE>
<TR>
<TD VALIGN="TOP" width="110">
<TABLE CELLSPACING=0 CELLPADDING=4 BORDER=0 >
<TR>
<TD> </TD>
</TR>
</TABLE>
</TD>
<TD></TD><TD></TD><TD></TD><TD></TD><TD></TD>
<TD VALIGN="TOP" width="500">bull
</TD>
</TR>
</TABLE></TABLE>
</BODY>
</HTML>
--CUT HERE--
Summary: layout wrong → layout wrong - wrong interpretation of cellpadding
here is a much, much better test case
<HTML>
<body bgcolor = "#FFFFFF" LINK="#0000FF" ALINK="#FF3300" VLINK="#FF0000">
<hr align=left width=110>
<TABLE CELLSPACING=0 CELLPADDING=20 BORDER=0>
<TR>
<TD VALIGN="TOP" width="110" bgcolor=yellow>x</TD>
<TD VALIGN="TOP" width="100" bgcolor=grey>bull</TD>
</TR>
</TABLE>
</BODY>
</HTML>
Assignee: buster → rickg
Status: ASSIGNED → NEW
Component: Layout → Parser
Summary: layout wrong - wrong interpretation of cellpadding → layout wrong - wrong handling of badly nested table tags
the regression is in the parser
the test case includes the following:
<TABLE CELLSPACING=0 CELLPADDING=10 BORDER=0 WIDTH=0>
<TABLE>
Nav throws away the second spurious <table> tag. The page layout depends on the
attributes of the first table tag. Unfortunately, it's the first table tag that
we throw away. This is very similar to the bug on the quicken page that
includes unexpected tags as children of <table>.
I verified that floaters are indeed returning the correct values.
Tables should nest (<table><table>...). Our content model stores them this way,
but it doesn't layout or render. If I propagate a <TD> to store the inner table,
it works. I've done this for now, and notified Steve Clark that nested tables
need to be improved.
ah, there were so many things wrong with this page, where to begin?
Kipp fixed the floating image problems and Rick fixed the parser problems.
That left 2 table layout problems.
1. <table width=0> was being treated as literally "give the table 0 pixels of
width" in which case the table would lay itself out in it's minimum required
width. Rational, but wrong. Width=0 is treated by Nav4 and IE as "auto width
layout." Now raptor does the same.
2. empty cells ("<TD></TD>") should rationally take up 2*cellpadding +
2*borderWidth pixels of horizontal space, and by golly they did in Raptor. But
not in Nav. Nav seems to add 3px. to the cell width in this case, as does IE.
So now we do too.
|
||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
|
|
||
Comment 7•26 years ago
|
||
This page is still laying out incorrectly. There is overlapping between the
tables. I'm not smart enough to know if it's a parser or layout problem.
Re-opening bug.
Rick needs to check in some fixes we made to the parser today before this page
is fixed. At that point, there may still be a little work to do. So I'll take
the bug.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
|
||
Comment 10•26 years ago
|
||
Paul, since you've been working with this bug, is it okay if I put
you in qa_assign to field? when you get chance you can regress this one..
|
|
||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
|
|
||
Comment 11•26 years ago
|
||
Hate to say it, but this page still has a problem. Again, I can't tell if it's a
parser or table problem. The image is not being aligned right. An ugly snippet
is below. This has some ugly HTML.
------------------------
<HTML>
<TABLE>
<TABLE>
<TR>
<TABLE>
<TR>
<TD> </TD>
</TR>
</TABLE>
<TD></TD><TD></TD><TD></TD><TD></TD><TD></TD>
<TD VALIGN="TOP" width="500">
<A HREF="dev/index.html"><IMG SRC="sonycomp.gif" WIDTH=85 HEIGHT=120 BORDER=0
ALIGN="right" HSPACE=20 ALT=""></A>
foo<BR></B> </FONT>
</TD>
</TR>
</TABLE></TABLE>
</BODY>
</HTML>
|
Reporter | |
Comment 12•26 years ago
|
||
changed misc bugs to M6
|
|
Reporter | |
Comment 13•26 years ago
|
||
setting my table bugs to M9
|
|
Reporter | |
Comment 14•26 years ago
|
||
Chris: somehow, a couple of table bugs slipped through my filter. reassigning
to you.
|
Assignee | |
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → WORKSFORME
|
|
Assignee | |
Comment 15•26 years ago
|
||
The url and included test cases appear to be fixed regarding the problem
reported. However, the testcase of 2/9 has a problem where if the floating image
cannot be found, the alt text doesn't show up unless the window is resized
smaller than the table width. I am going to file a separate bug on this.
|
||
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 16•26 years ago
|
||
verified worksforme
You need to log in
before you can comment on or make changes to this bug.
Description
•