Closed Bug 30988 Opened 25 years ago Closed 24 years ago

[P-Margin] FORM tag causes spacing different than Nav4.x, IE 5.x

Categories

(Core :: Layout: Form Controls, defect, P2)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: frank, Assigned: buster)

References

(
URL
)

Details

(Keywords: compat)

From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (WinNT; U) BuildID: 2000022820 Adding a FORM tag causes other elements to be pushed down. This is not the case with Nav 4.x or IE 5.x. The URL above is a real world example of what the bug causes, but I have also encluded a very small test case below. Reproducible: Always View the HTML below in Mozilla and Nav 4.x with and without the FORM tags. Mozilla adds extra spacing, Nav 4.x does not. <HTML><BODY> <FORM> <P>Hi</P> </FORM> </BODY></HTML>
moving over to form submission and reassigning. could not find anythign similar on bugzilla
Assignee: rickg → rods
Component: HTML Element → Form Submission
QA Contact: petersen → ckritzer
confirming bug, but I am prettty sure this is a dupe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually on Macs, Communicator 4.x DOES do this, but not quite to the extent that Mozilla does. As a content developer I find it extremely frustrating that NC and Moz do this. There is no reason in the world why a form should introduced what amounts to an <P>&nbsp;</P> after the form ends, for no reason. Forms are NOT block level text elements like <P>, they are delineators of functionality (much less block level elements that need or expect whitespace around them, e.g. <H1>, <BLOCKQUOTE>, etc. I find that the spacing placed around <DIV> is just as bad. Basically we have <DIV> and <SPAN> that's it, but in many instances you can't get away with, say, <SPAN><P>blah</P></SPAN>, although I don't find anything in the HTML specs forbidding this. That just leaves <DIV>, but <DIV> messes up your layout if you are doing fancy table-based layout. <FORM> does this too, and it's just completely senseless. For an example, look at the EFFector form in the left-hand menu at http://www.eff.org WARNING: Do NOT attempt to view this page in M16, at least not on a Mac. I causes 'Zilla to crash; that's a topic for another bug report entirely.) Compare it to the result in IE. See also the Search/Browse form at the top of the page. They look like total dookie in Mozilla, due to the extraneous whitespace. This is one Netscape "quirk" that is NOT work repeating, and if I were in a position to influence Communicator-working cohorts at netscape.com, I'd strongly encourage them to fix it in Netscape, too. Especially if it already HAS been fixed in the Windows version, which is what is sounds like from the origin
Buster, this might be a dup. The following example creates an 8 pixel margin between the top of the form and the top of the document: <html> <body bgcolor="#c0d0f0"> <form style="background-color:blue">text<P>A paragraph</P> <br> </form> </body> </html> The following example creates an 16 pixel margin between the top of the form and the top of the document: <html> <body bgcolor="#c0d0f0"> <form style="background-color:blue"><P>A paragraph</P> <br> </form> </body> </html> The only thing I did was remove the text in front of the paragraph. I don't think the space from the top of the doc to the top of the form should vary depending on what is inside the form. Buster, I am reassigning this to you. It is a block or line layout issue as far as I can tell. adding troy and self to cc list
Assignee: rods → buster
this is an instance of the P-Margin error. I hope to get to this next week.
Status: NEW → ASSIGNED
Priority: P3 → P2
Summary: FORM tag causes spacing different than Nav4.x, IE 5.x → [P-Margin] FORM tag causes spacing different than Nav4.x, IE 5.x
Target Milestone: --- → M17
M17 has come and gone. Is this bug still on anybody's radar?
PDT: Marking nsbeta3+ Reason: Customer escalation.
Whoa. Which problem are we talking about here? The margin-below or the margin-above? The margin-below is a 3 character fix that I can do while fixing ua.css. That is, IF we want that. I'm assuming there is a reason for our bottom margin; I may be wrong (I would investigate if I had to fix that). If it is the margin-above problem, then this is a {compat} issue -- our current behaviour is CORRECT according to the spec. Which customer escalated this? Some very quick changes to their stylesheet would fix all these problems. ChrisK: You didn't actually mark this bug nsbeta3+. Did you get the wrong bug?
I'd say margin-below is the issue, and it should be nsbeta3. However, I think this is a dupe still...
FYI: Opened bug #50695 to track a related issue - a TABLE inside a FORM cannot set its HEIGHT to 100%. This is the bigger issue for us.
Updating QA contact.
QA Contact: ckritzer → vladimire
P2 bugs will not make RTM. Milestone -> Future. Frank, if you want to push for this bug being escalated to P1, please state your case here in the bug report. If a simple workaround exists, we may ask that you pursue it instead. If you are stuck because of margin bugs in the block code, I could take a look, but it would have to be in the next few days.
Target Milestone: M17 → Future
If we don't fix this for RTM, -> WONTFIX. It's a compat bugas as far I can tell.
Keywords: compat
Buster, thanks for the offer to take a look at the problem. Our next release has already gone gold, and includes a workaround for this problem, so I don't care if this gets a WONTFIX. The bigger (related) issue for us is bug #50695, for which there is no workaround for. Any chance of that bug getting escalated?
This looks like a duplicate of bug 41086 (which is explicitly focused on the problem of form margins and includes more relevant discussion of Mozilla's current behavior).
URL looks sane to me, and 41806 is marked FIXED...closing as WORKSFORME.
Component: Form Submission → HTML Form Controls
Really closing, sorry. bz: I was removing cc's because I went through and did general housekeeping in layout-troy no longer with us, and bstell was assignee on 92590, hence no longer needed cc-removed when I added keyword.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
wfm branch build 09/24
Keywords: vtrunk
verifying on 2001-10-03-03-trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.