505 bytes, text/html
2.28 KB, text/plain
** Observed with 20011009 Wi32 trunk/branch builds ** If you look at the above URL, you can see that the 2nd form is aligned at the top while the 1st one is one line below due to the existence of <P> tag. Both have <valign=top> specified and both have <P> specifing a paragraph block. Marcio and I reduced the above to a near-minimum test case: ============================================ !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <BODY> <TABLE border=1 width="100%"> <TR> <TD vAlign=top> <FORM> <P><SELECT> <OPTION>test1 </OPTION> </SELECT> </P> </FORM> </TD> <TD vAlign=top > <FORM> <input type=hidden name=gotoit value=1> <P>test2 <input type=text name=gotoit> <input type=submit value=go> </p> </FORM> </TD> </TR></TABLE></BODY></HTML> ============================================ With Mozilla, 2 input fields are not aligned at the top. Instead they look like the following: _____________________ |_____________________| _____________________ |_____________________| WIth IE5.5 and NN4.78, they are aligned at the top. For this effect in Mozilla, it is critical where the the 2nd <P> begins. If it begins after the 1st <input type=hidden ...> line, then <vAlign=top> is honored and <P> is ignored. If it begins before the 1st <input type=hidden ...> line, then the <P> is honored and <vAlign=top> is ignored and this moves the 2nd input field downward to align with the 1st input field. On the other hand, if we move the 1st <P> to the position after the <SELECT> element, then <vAlign=top> is honored. IE5.5 and NN4.78 behave exactly the same even when the <P> position is moved as described above. The web page cited above (which is one of the frames for a main page) is causing a layout problem for Mozilla because both fields don't align at the top as apparently intended by the web page creator. Is this Mozilla's bug? or is this as it should be? In either case, we have a practical problem to solve and we need a definitive answer.
Sorry - I messed up the doctype in the testcase I attached - ignore it since it does not matter anyway. Something interesting: If I add borders to the form, for example, then both cells get the contents in the middle (eg. valign=top appears to be ignored). Also, if I do that then the DIV case fails too. If I add borders to the DIV, then it has the problem too. Seems like it is not a table problem, it is something in the blocks I think.
Status: NEW → ASSIGNED
Sounds like margin-collapsing is going on to me.... Question is, why is it not happening in one case without the borders (borders would force margins not to collapse).
Borders should not have any effect at all on margin collapsing. If Mozilla is letting the presence of borders affect the handling of margins then there's a serious problem. Do we have a test case to show one way or the other?
Eric, what about something like: <div style="padding: 0; border:0; margin:0"> <p style="margin: 2em" /> </div> <div style="padding: 0; border:0; margin:0"> <p style="margin: 2em" /> </div> Would the margins of the two <p>'s not collapse together in this case? And would not putting a border on the outer <div>s keep the margins from collapsing?
bz is correct; emeyer is correct only as far as siblings go.
Your points are correct, Boris; I had misunderstood the situation. I'm not thrilled with the fact that nested margins collapse at all, but it's in the spec so I guess we're stuck with it. Sorry for the unnecessary traffic.
The remaining issue, margins inside the tables is bug 33784 "[MARGIN-C]margins not collapsed at cell edges in quirks mode". Build 2002-01-04-03 (trunk) on Windows 98. *** This bug has been marked as a duplicate of 33784 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.