Closed
Bug 104000
Opened 24 years ago
Closed 24 years ago
The effect of <P> element is not observed when another elment tag is present
Categories
(Core :: Layout, defect)
Tracking
()
mozilla1.2alpha
People
(Reporter: momoi, Assigned: attinasi)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
** 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.
|
Reporter | |
Comment 1•24 years ago
|
||
CC'ing karnaze.
|
|
Assignee | |
Comment 2•24 years ago
|
||
|
|
Assignee | |
Comment 3•24 years ago
|
||
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
|
|
Assignee | |
Comment 4•24 years ago
|
||
|
|
||
Comment 5•24 years ago
|
||
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).
|
|
||
Comment 6•24 years ago
|
||
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?
|
|
||
Comment 7•24 years ago
|
||
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?
|
||
Comment 8•24 years ago
|
||
bz is correct; emeyer is correct only as far as siblings go.
|
|
||
Comment 9•24 years ago
|
||
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.
|
|
||
Updated•24 years ago
|
Target Milestone: --- → mozilla1.2
|
||
Comment 10•24 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•