From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (WinNT; U) BuildID: 2000070220 A FORM with the CSS style display:inline and without margins or padding will be rendered as block-element. Reproducible: Always Steps to Reproduce: 1. Create a page with two forms. 2. Set both to display:inline 3. Load the page Actual Results: The second form will not be displayed inline. Expected Results: The second form should be displayed inline. Works fine with IE5.

I confirm the problem on Mac 2000-07-06: FORM elements ignore the "display:inline" declaration. The problem is in the FORM element itself, not in the form controls. See the testcase that I'm going to attach. Reassigned to Waterson.

Seems reasonable to want this fixed.

As per meeting with ChrisD today, taking QA.

[nsbeta3-] and FUTURE.

*** Bug 63309 has been marked as a duplicate of this bug. ***

See also bug 62811.

Using display:inline !important will work since it overrides the following in html.css: form { display: block !important; } Is there a reason why that declaration is flagged !important? Removing it may get us halfway there. However, the form still doesn't have true display:inline behavior. Its right edge extends to the far right of its containing block, kind of like a block element, but then when you resize the window its right edge stays at the point where they window was the smallest. Will attach testcase.

Probably the reason it's marked as !important is the broken behavior you see when it isn't. I think fixing this requires moving form data/submission logic from frames into content so that we don't need to use special frame types for forms.

What dbaron said.

SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.

Another case: http://johnwarburton.net/hyptest/testform.php Just noticed this today. !important makes some controls fly off the right of the screen... and very strange things happen when you click the "HIDE/UNHIDE" button (it, too, flies off to the right without executing the "action" of the form). Linux nightly 2001091008

Note that this bug also happens if there is only one form on a page. Cf. www.flocat.com. The search box has extra space not there in all the most commonly used browsers. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/2001112009

*** Bug 122622 has been marked as a duplicate of this bug. ***

cc'ing jkeiser. How much of this work has been accomplished? I know form controls have changed a lot since comment #10.

*** Bug 123470 has been marked as a duplicate of this bug. ***

If removing the form frame entirely will fix it, then I'll take this. *Provisionally* setting milestone to 1.0. If it is as easy as I think it will be once I get bug 108308 out of the way, it's already in my sights.

Moving to Moz1.1 to get it off the Moz1.0 radar. John if you get through your nsbeta1+ bugs please add nsbeta1 to nominate it and I'll move it back to Mozilla1.0.

Fixed with bug 125578. There is no chance it will get into 1.0.1 or any point release thereafter, however. The fix is just too big.

(Resolving fixed)

*** Bug 154897 has been marked as a duplicate of this bug. ***