I'm not even sure of the reason that Compuserve chose to do this, but for their current home page, they set a style of "form {display:inline}". On that home page, they have a form in the upper right hand corner, which contains two <INPUT type=text> elements inside of a 150px wide TABLE. This combination leads to some odd layout, where the text elements protrude out the right-hand border of the TABLE. If I replace the TABLE with a fixed-width DIV, the same effect occurs, so this is some form of a block problem (no pun intended). I'll attach a simple testcase.

yep, it sure looks like me

Block Buster this: http://members1.chello.nl/~j.c.drost/mozilla/sm62811-1.html Are you waiting for an extra job Buster? Well, I got something for you, if you like, and it's all about tables/layout Just asking, and no kidding! I consider using forms inside a table, a bad habbit! Friendly, HJ.

Adding mysel to cc list

John, can you use my work around for now? please clarify, yes or no?

Er, um. It's not really a question of whether I can use a workaround or not. (Me, personally ... I don't need a workaround at all. It's not my page :-]) I noticed this bug on Compuserve's home page, and the behaviour is not correct. Buster, can make the call on how vital it is to fix.

And all the people using Netscpae6/6.0 they will have to wait for the upcoming version 6.5?? And hey, if you where the owner, you won't be working for Netscape! Hihi.

bug 44470?

bug still occurs in win32 build 2001-04-18-09 build. Nominate for nsbeta1.

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

... which reminds me. We need to either fix this, or conduct a short seminar for the Compuserver web masters :-]

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

Clearning milestone to trigger re-evaluation for mozilla 0.9.1. Here's a screenshot: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34691 happens right when you go to http://www.compuserve.com Yuk! Looks real bad!

Is this something that has to be changed on our side? Can a workaround be given to CS until we have a fix?

Adding Marcio Galli, who will be the point of contact on the Evangelism team.

Moving to m0.9.2. I would prefer to fix it on our end because other pages could do the same thing. I will be attaching a low risk patch to ensure that <form>s are display:block (which is all we can support without a lot of difficulty).

I that hyatt is trying to remove any frame-level mutation of the style context once its been created...

If hyatt can do this with his new stuff, great. But until then, this is probably the best way to do it (after talking to attinasi). There are already other places in the code where frames are doing similar things (so hyatt may need to fix those as well). Finding them won't be difficult (they should contain something like nsMutableStyle...)

r=pollmann@netscape.com, looks good!

Is this targeted at 0.9.2 or 0.9.1? If it's at 0.9.2, then this fix should not go in, since I have eliminated frame-level mutation of style data. If you need to get it in by beta, then never mind. Just check it in. :)

WOuldn't a much simpler fix be to just add the following line to html.css? form { display: block !important; } I don't think you need to alter C++ code here.

If someone specifies <form style="display:inline"> it will currently override the !important in the ua.css because the style attr. has infinite weight in our cascade, so the C++ change is safer I think. sr=attinasi for patch 34957, if you decide you want it.

you can still check this in until 11:59 Friday, 18/May/01.

Marc, that's not true. Important rules in an agent sheet beat inline style.

I tested the above test case by putting style="display:inline" on the form elements themselves. This was overridden by an important rule setting display to block, so IMO the html.css patch is a better way to go here.

OK, I believe you David. I agree that the style rule is an easier change to swallow too. The only remaining problem could be an author-supplied rule with !important, but maybe that is not worth worrying about.

David, I checked in the patch before the last few comments. The patch is simple and does handle the case that Marc mentions (!important author), whereas the style rule change does not. So, I think we should leave the change in until we can support inline <form>s. This also seems to illustrate that we may not be able to remove frame-level mutation of the style system until frames support everything that can be specified through style.

The fact that !important in a UA stylesheet is overridden by an author-level !important rule is bug 45852. karnaze: Since you checked the patch in but didn't mark this bug FIXED, I'm assuming you are leaving it open because the real bug (<form> doesn't support being 'inline') has not yet been fixed. Is this correct? If so, this bug is now a duplicate of bug 44470.

Ian, I just wanted to wait a little while. Marking fixed. I'm a little confused by your last comment, since bug 45852 says: According to both the CSS1 and CSS2 specifications, all rules in the the author stylesheet completely override the UA styles, regardless of !important status. This is not happening in Mozilla.

I disagree with your assertion that this is a good reason why mutable style data is necessary. This entire patch is a hack to work around the fact that we don't support inline forms. The style rule would have handled any practical Web page and should have been good enough. I will add the style rule to my branch and when I merge in with the tip, I'm going to back this out.

Just as a heads up - I plan on removing nsFormFrame as part of bug 34297. I'm moving all the form submission and management logic to content land, and there is nothing else of interest in nsFormFrame. This should, I think, eliminate the need to change html.css. One thought - and take this with a grain of salt because I am not familiar with the issues here - re: why mutable style is a bad thing. :) Won't this change to html.css encourage authors to create pages that specify the !important when they shouldn't need to? This seems bad. Either authors specify block:inline and we support it or we don't - but forcing author !important for every little change diminishes !important. This is in my opinion, a bad tradeoff of creating a web full of hacks (long living, as evidenced by the current state of the world) instead of a client full of them (transient, as evidenced by the fact that nsFormFrame is going away entirely).

s/block:inline/display: inline/; I can't type... :)

karnaze: yes, the first comment of that bug is incorrect. pollman: putting a !important rule in html.css would not encourage authors to use !important, would it?

> putting a !important rule in html.css would not encourage authors to > use !important, would it? Not directly, but if we ship with a browser that allows user !important to override html.css !important (bug 45852), and designers discover that specifying display:inline !important will change our layout behaviour to whatever advantage, they *will* use it, even it it isn't doing the right thing. Better to just not support display:inline on forms at all (even with user !important, hence Chris's change) than this, right?

pollmann: you may be right that it's better to leave the display type unsupported (until this bug is fixed in an agreeable fashion, whether via C++, CSS, or both), but it is *not* better to leave the hack of GetMutableStyle around. /be

pollman: The erroneous assumption you are making is that it would "change our layout behaviour to whatever advantage". Our behaviour resulting from having display:inline on a <form> is in no way advantageous, indeed it is horrible. :-)

Verifying on build 2001-05-22-04-trunk windows 2000