Closed Bug 104000 Opened 23 years ago Closed 23 years ago

The effect of <P> element is not observed when another elment tag is present

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 33784
Milestone:
mozilla1.2alpha

People

(Reporter: momoi, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(2 files)

testcase: showing the problem in tables, but not in divs
505 bytes, text/html
Details
frame dump to the two DIV cases - why is the first div taller?
2.28 KB, text/plain
Details 
** 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.
CC'ing karnaze.
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.
Target Milestone: --- → mozilla1.2
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
Closed: 23 years ago
Keywords: testcase
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: