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

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[John Morrison]

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.

Comment 1

[John Morrison]

Attachment: testcase; form{display:inline} inside fixed-width table or div

Comment 2

[buster]

yep, it sure looks like me

Comment 3

[HJ]

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.

Comment 4

[HJ]

Adding mysel to cc list

Comment 5

[HJ]

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

Comment 6

[John Morrison]

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.

Comment 7

[HJ]

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.

Comment 8

[Fabian Guisset]

bug 44470?

Comment 9

[lchiang]

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

Comment 10

[Conor Lennon]

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

Comment 11

[John Morrison]

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

Comment 12

[John Morrison]

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

Comment 13

[Peter Lubczynski]

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!

Comment 14

[lchiang]

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

Comment 15

[Chris Nalls]

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

Comment 16

[karnaze (gone)]

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).

Comment 17

[karnaze (gone)]

Attachment: patch to ensure that forms are display:block

Comment 18

[Chris Waterson]

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

Comment 19

[karnaze (gone)]

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...)

Comment 20

[Eric Pollmann]

r=[e-mail], looks good!

Comment 21

[David Hyatt]

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. :)

Comment 22

[David Hyatt]

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.

Comment 23

[Marc Attinasi]

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.

Comment 24

[Marek Z. Jeziorek]

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

Comment 25

[David Hyatt]

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

Comment 26

[David Hyatt]

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.

Comment 27

[Marc Attinasi]

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.

Comment 28

[karnaze (gone)]

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.

Comment 29

[Hixie (not reading bugmail)]

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.

Comment 30

[karnaze (gone)]

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.

Comment 31

[David Hyatt]

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.

Comment 32

[Eric Pollmann]

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).

Comment 33

[Eric Pollmann]

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

Comment 34

[Hixie (not reading bugmail)]

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?

Comment 35

[Eric Pollmann]

> 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?

Comment 36

[Brendan Eich [:brendan]]

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

Comment 37

[Hixie (not reading bugmail)]

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. :-)

Comment 38

[Vladimir Ermakov]

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