Closed Bug 1725 Opened 24 years ago Closed 23 years ago
content missing, parsing error for <form> in <table>?
Does not layout the text fields in the correct place. Labels on text fields are missing. Text at bottom of page is also messed up.
There is a lot wrong with this page. It is my guess that it starts with parser problems, but it's hard to tell. If you remove the <form> and </form>, the table lays out correctly. Once this problem is fixed, there are other problems on this page that might get cleared up. Style is wrong for the text, and the submit button is too large. <html><body> <TABLE Border=0 Cellpadding=0 Cellspacing=0 bgcolor=pink> <TR> <TD COLSPAN=3 Width=600 Align=Left VAlign=Top bgcolor=yellow>1</TD> </TR> <TR> <TD ALIGN=LEFT Width=600 COLSPAN=3 bgcolor=red>2</TD> </TR> <TR> <TD Width=150 ROWSPAN=40 COLSPAN=1 Align=LEFT VAlign=TOP bgcolor=aqua>3</TD> </TR> <FORM action=/cyberhomes/templates/summary.cfm method="GET"> <TR> <TD WIDTH=430 bgcolor=orange> <TABLE BORDER=0> <TR> <TD WIDTH=215><input type=submit VALUE="Submit Criteria"></TD> <TD align=left WIDTH=215>4</TD> </TR> </table> </TD> </TR> </FORM> <TR> <TD ALIGN=LEFT WIDTH=430 bgcolor=red>5</TD> </TR> <TR> <TD ALIGN=LEFT WIDTH=430 bgcolor=yellow> If you have entered your feature criteria, press the "Submit Criteria" button above. </TD> </TR> <TR> <TD ALIGN=LEFT WIDTH=430 bgcolor=lightgrey>6</TD> </TR> <TR> <TD ALIGN=LEFT WIDTH=430> If you want to do a radius search instead, press the "Radius Search" button. This will allow you to select a starting point and enter a radius with new feature criteria. </TD> </TR> <TR> <TD ALIGN=LEFT WIDTH=430> </TD> </TR> <tr> <TD ALIGN=LEFT WIDTH=430> All information provided is deemed reliable but is not guaranteed and should be independently verified. The price shown may represent the top or bottom of a price range listing and not necessarily a fixed price offer. </TD> </TR> </TABLE> </BODY> </HTML>
This is not a parser bug -- the content model dumps correctly. Its either a text problem or a style problem, so I'll give you first crack.
Setting all current Open Critical and Major to M3
Assignee: kipp → karnaze
Status: ASSIGNED → NEW
Component: Parser → HTMLTables
The form element was a red herring; if you take out the "rowspan=40" out of the test then the table lays out much much better. The result of the rowspan seems to be that the table code ends up shrinking the size of each row too much (smaller than the intrinsic size of each row).
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
There are 2 problems (1) We honor the width attribute on a cell and Nav4.5 doesn't appear to and (2) The presence of the <form> inside the rowgroup is causing a cell to think it is in the wrong row (a taller row) for placement calculations, causing it to place its area frame at a much lower position. I didn't realize that in this example a row could have a 0 height. I need to talk to Steve. The following very simple example illustrates the problem. As Kipp pointed out, by reducing the rowspan value, the 2nd problem goes away also. <html><body> <TABLE Border=0 Cellpadding=0 Cellspacing=0 bgcolor=pink> <TR> <TD Width=50 ROWSPAN=3 valign=top bgcolor=aqua>one</TD></TR> <FORM></FORM> <TR> <TD WIDTH=100 bgcolor=orange>two</TD></TR> <TR> <TD bgcolor=yellow>three three three three three three</TD></TR> </TABLE> </BODY></HTML>
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Problem (2) in my last comments has been fixed. Problem (1) is a Nav4.5 compatibility issue (both IE5 and Gecko honor the width of a <TD>). We may never decide to provide backward compatibility on this issue, because it will cause a lot of work and will deviate more from the standard than the current behavior.
Using 3/18 build, verified fixed.
You need to log in before you can comment on or make changes to this bug.