Closed Bug 91602 Opened 23 years ago Closed 23 years ago

Input field and adjacent select/option field within the same form have different heights

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: rods)

References

(
URL
)

Details

(Keywords: intl, topembed)

Attachments

(6 files)

English test case. Save it as test1.html. This one contains no DOCTYPE declaration.
877 bytes, text/html
Details
Japanese test case. test2.html. The unbalanced input field sizes are even more noitceable. Contains no DOCTYPE declaration.
876 bytes, text/html
Details
Simple testcase: no form, no table: select size=1 is not tall enough
593 bytes, text/html
Details
Minimal Patch using #define USE_FORM_QUIRKS
10.29 KB, patch
Details | Diff | Splinter Review
Japansese screen shot showing it to be improved
19.16 KB, image/jpeg
Details
patch using prefs for turning on the old way
10.76 KB, patch
Details | Diff | Splinter Review 
|** Observed with 7/19/2001 Win32 build  **

The behavior here is quite similar to another bug in which 
I reported on the height value being ignored within the img tag.
This is Bug 91550. This leads to unblanced layout that quite a number
of evangelism bugs from Japan have reported. 

The form input field immediately followed by a option selection 
field are used on many web page. 
The propblem is that these 2 fields arranged side by side do not 
use the same height for the fields and thus cause unbalanced
layout which looks like the following:

   Input field                 Select/option field
 ____________________      ______________________
|                    |    |______________________|                      
|____________________|  

There are no font size specifications for either of these boxes and
so the should use the same height for the box. Yet as can be
seen from the test cases I attach below, the font sizes within the
2 boxes are different and thus the fields are drawn in different
sizes.

Notes:

1. This problem does not occur with IE 5.5 or Comm 4.x
2. This problem does not occur under certain DOCTYPE 
   declarations.
Re-assigning this to attinasi.
Assignee: karnaze → attinasi
Compare the display with IE and Comm 4.x. Both display the
height of the 2 input fields as the same under all of the
followingt DOCTYPE declarations. Yet Mozilla behaves differently
depending on DOCTYPEs.

Here are the DOCTYPEs under which Mozilla displays the height of the
2 input fields exactly the same:

1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

2. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
            "http://www.w3.org/TR/html4/strict.dtd">

3. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">


Here are the DOCTYPEs under which Mozilla displays the height
of the 2 input boxes as different:

4. No DOCTYPE declaration 

5. <!DOCTYPE HTML PUBLIC  "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

6. <!DOCTYPE HTML PUBLIC ""-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/frameset.dtd">

7. <!DOCTYPE HTML PUBLIC  "-//W3C//DTD HTML 4.01 Transitional//EN">

8. <!DOCTYPE HTML PUBLIC ""-//W3C//DTD HTML 4.01 Frameset//EN">

Note in particular the difference between 1 and 5. They are
both widely used DOCTYPE URLs and believed to be the same DOCTYPE
URL and yet the behavior here is different. Also many pages have
no DOCTYPE declaration and thus siffers from this problem.

This bug and Bug 91550 account for a sizable number
of look/apperance problems reported for Top 100
Japanese web site testing.


Changing severity to major.
Severity: normal → major
There are many web pages with this problem. 
I cite one (Netscape Japan Home Page) at the URL above.
URL: http://home.netscape.com/ja
shanjian, do you think your comment in Bug 41461 might
explain this problem, too?


> shanjian, do you think your comment in Bug 41461 might
> explain this problem, too?

Maybe not. Changing the locale setting makes no difference
in the problem described here.
I looked briefly for a Quirk that might be causing this but could not find any.
Over to Rod S. to look at (note: he is out for several more weeks, so if this
needs to be fixed soon for some reason please send it back to me with an
explanation of the urgency).
Assignee: attinasi → rods
Keywords: intl, nsBranch
Keywords: topembed
Here are the issues:

1) Nav 4.x (in English) is NOT sizing thenm as the same height. The select is
always two pixels smaller than the text field. That is because when the doctype
is not interpreted as "strict" the sizing defaults to "Quirks" mode which makes
them different sizes.

2) When the doctype is interpreted as "strict" it is the "standard" algorithm
for sizing and then the turn out to be the same size. I think, Marc and I event
discussed doing away with the Quirks sizing of one of the controls before I was
gone (buttons or text fields). 

3) Maybe we should just drop Quirks sizing for text fields altogether. This can
easily be done.
Status: NEW → ASSIGNED
I don't understand why this bug have "intl" keyword in it. There are nothing 
special for internaionl uage here. 
This bug has correspondign NS internal bugs which are found on
many Japanese sites. That is the reason why this has "intl"
keyword on it. The porblem is magnified on CJK fonts.
I agree with FTang. The problem is magnified for CJK, but this is a CORE issue.
The "minimal" patch above allows you to revert back to the way it was before by
defining the compile time define USE_FORM_QUIRKS.

NOTE: I have removed all form control quirks from the "quirk.css" not just the
text field and buttons. This will also speed up rule resolution.

If we go with these changes, I can open a bug for completely removing all the
Quirks code.
The Japaneese example above looks much improved. 

Could somebody try out my patch and do some extensize testing on some Japanese
sites? Thanks.
Rod, just to be certain about the effect of this change,
are you adjusting 
1) input filed height to be smaller, or
2) control field to be larger, or
3) combination of both

to get the effect you show in your attachment?
What I see in IE 5.5 using Japanese examples is that
the input field height/fonts generally match 
the default font size. I am wondering if the suggested
change will lead to default font size height in
input field unless there are specific size specified
via stylesheet.
The change now means it will always size like it sized before for documents with
DTDs that were "loose" or "strict" 

Which means it will use the default font for determining the height and width
and will size very closely yo how IE sizes things. NavQuirks had some bizarre
algorthims for sizing things.
The most recent patch turns off quirks, but you have to add in the old rules to
the quirk.css that have been removed. To turn on quirks add this to your prefs:

user_pref("layout.forms.use_standard_or_quirks", true);

Patch looks good. Please change the mods to quirk.css so it is just one big
annotated comment block instead of removing the rules (to make it easier to
toggle the rules if somebody wants to set the pref to cause the old quirk
behavior) and sr=attinasi
r=dcone
fixed and Quirks can be turned back on using pref:

user_pref("layout.forms.use_standard_or_quirks", true);
ok, really fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
just a minor issue

use_standard_or_quirks true/false

true -> standard or quirks
false -> none of them

This is what a normal mind would understand, so couldn't this be called
something like use_quirks_mode_for_height or so, where someone could definitely
say true means this and false means that?
Keywords: nsBranch → nsbranch
Marking verified per last comments.
Status: RESOLVED → VERIFIED
Keywords: nsbranch → nsbranch+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: