Closed Bug 62811 Opened 24 years ago Closed 23 years ago

"form {display:inline}" inside fixed-width DIV or TABLE distorted

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: jrgmorrison, Assigned: karnaze)

References

(
URL
)

Details

(Whiteboard: anybody really want to go to beta like this?)

Attachments

(2 files)

testcase; form{display:inline} inside fixed-width table or div
843 bytes, text/html
Details
patch to ensure that forms are display:block
1.53 KB, patch
Details | Diff | Splinter Review 
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
Severity: normal → major
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla1.0
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 still occurs in win32 build 2001-04-18-09 build.  Nominate for nsbeta1.
Keywords: 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 :-]
Assignee: buster → karnaze
Status: ASSIGNED → NEW
Keywords: mozilla0.9.1
*** Bug 81126 has been marked as a duplicate of this bug. ***
Whiteboard: anybody really want to go to beta like this?
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!
Target Milestone: mozilla1.0 → ---
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).
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Blocks: 86633
Depends on: 651274
No longer depends on: 651274
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: