55336 - [FIX]<input type=text>: border & padding problems (reintroduced?)

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P2)

Description

[Klaus Malorny]

Versions: NS6PR3, daily build 2000092908

For text input fields, borders & vertical padding do not work correctly.

Regarding borders, the size is always set to 2px and the style always set to 
'inset', ignoring the style specified via CSS. On text areas it works 
correctly (see test case). It seems to me that a problems has been 
reintroduced, since one of the earlier builds (~ a month ago) worked correctly. 

Regarding padding: Although the padding is taken into account for the control's 
inner formatting (i.e. the text entered), the height of the control is not 
adjusted accordingly (which it should do, since it does not have a vertical 
scroll bar in contrast to the textarea control), resulting in text that is cut 
of horizontally.

Comment 1

[Klaus Malorny]

Attachment: Test case showing effects of CSS border and padding properties to input/text and textarea elements

Comment 2

[Klaus Malorny]

the file res/quirks.css contains a rule

/* Quirk: text input has fixed look in compat mode (b=25580) */
input[type="text"] {
  border: 2px inset ! important;
  padding: 1px 0 0 0;
} 

I temporarily removed the line with !important and then the border problem 
disappeared. Not being in the matter, I don't know why this is so '!important', 
but probably you do ;-)

Comment 3

[James Lariviere]

I'm sending to over to html form controls.

Test case probably renders this way because of the missing dtd line, so mozilla
renders in quirk mode.

I'll put up a new test case under strict mode... you can see mozilla renders as
author desired.

Comment 4

[James Lariviere]

Attachment: same test case - but strict dtd

Comment 5

[Hixie (not reading bugmail)]

In compatability mode, we are attempting to be compatible with Nav 4.x.
If the author wants good control of his widgets, he can use strict mode (i.e.
write valid documents) and then he'll get what he wants.

This should be fixed with XBL widgets anyway.

We do make rather a mess in this case though, so maybe it's valid...

Comment 6

[James Lariviere]

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

Comment 7

[bora123]

Klaus is right, what is "! important" for in the file quirks.css? it works 
exactly expected without it. 

Comment 8

[rods (gone)]

Since Nav 4.x doesn't obey border & padding, neither should input text or 
textarea in quirks mode.

This is what the quirks.css should have:
/* Quirk: text input has fixed look in compat mode (b=25580) */
input[type="text"], textarea {
  border: 2px inset ! important;
  padding: 1px 0 0 0! important;
} 

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[James Lariviere]

Rod, I think some of the confusion here is why is this rule is just for
input[type="text"] and textarea (s).  NAV4 screwed this up on ALL form elements.

In duplicate reports, people seem to commonly ask why they can change border
styles, etc. in other form elements except these 2.  IMO, I wish we could take
out this rule entirely out of quirks.  Why penalize web developers more...
whatever. I know, old discussion. :-)

However, for the better *cough* I think we should add all form elements to this
rule.  It does not seem consistent that you can style radio/checkboxes etc. but
can't with textarea/text inputs. :-)

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[bora123]

why dont you put one more mode so that we can utilize the full advantage of 
standards? I personally do not wish to use that ugly border of textarea and 
input/text, and rather would like to define my own border.

Comment 17

[bora123]

What is really bad going to happend if web developers can style the borders of 
the textarea/input=text? As far as I know Nav4 ignores border styling for form 
elements. What is really back compatible here for not letting anybody touch the 
borders of textarea/input=text on Mozilla?

Comment 18

[rods (gone)]

I think the "important rule should be there for all the forms controls for 
quirks, instead of removing it for these two.

The reason is, we can't remove it for these two or the control sizes 
incorrectly. Meaning is the border or padding is increased it grows inward 
"eating" up the internal space of the text field. We do this because of the 
sizing algorthim for NavQuirks.

Comment 19

[rods (gone)]

Attachment: patch file for quirk.css

Comment 20

[bora123]

hmm, I do not know if you have really used strict.dtd and loose.dtd. Eventhough 
you can set the borders for form elements, These modes are missing tons of 
stuff. I am almost certain that nobody will use these two modes unless they 
worship dinasours. For the so called quirks mode, it has on the other hand all 
the juice except now this NEW border styling rules. You are leaving no space 
for us but wait the third party gecko browsers which ships without these 'to 
me' unacceptable style restrictions. Meaning, I will check the browser type and 
skip Mozilla or Netscape 6, but will go for third party gecko browser 
signatures which removes this restrictions. I am pretty sure there will be one 
or two.

Comment 21

[rods (gone)]

I do not have to check these in. But it is not worth the time to fix the input 
type=text to allow developers to set borders to anything larger than 2 pixels. 
(Menaing the text controls will always size 24 pixels high no matter what the 
padding and borders are set to)

In fact, if people really want, I can even remove the "! important" on the text 
control in quirks, reopen the original bug and mark it "Won't Fix".

This would enable the greatest flexibility for web developers as they move their 
content from pre-HTML 4.x markup to strict mark up. 

Here would be the new patch:
Index: quirk.css
===================================================================
RCS file: /cvsroot/mozilla/layout/html/document/src/quirk.css,v
retrieving revision 1.13
diff -u -r1.13 quirk.css
--- quirk.css   2001/01/12 20:11:32     1.13
+++ quirk.css   2001/02/21 21:11:03
@@ -88,18 +88,14 @@
   white-space: -moz-pre-wrap;
 }

-
 /* Quirk: text input has fixed look in compat mode (b=25580) */
 input[type="text"] {
-  border: 2px inset ! important;
   padding: 1px 0 0 0;
 }


-/* Quirk: text inputs and textareas have special font (b=44656) */
 /* dealt with at the code level */

-
 /* Quirk: special margins for radio buttons */
 input[type="radio"] {
   margin: 2px 5px 4px 3px;
@@ -112,7 +108,6 @@
   margin: 3px 4px 3px 3px;
   vertical-align: bottom;
 }
-

 /* Quirk: special top and bottom margins for inputs in tables */

Comment 22

[bora123]

"In fact, if people really want, I can even remove the '! important' on the 
text control in quirks"

Rod, please remove the '! important' from quirks.css for the text controls. In 
fact, please do not use any '! important's in quirks.css :).

Comment 23

[James Lariviere]

rod,

your patch to quirks.css was exactly what I was thinking of (2-05-01 post). :-)

I think that this is probably the most consistant way to render form controls
while still allowing the borders to be altered in strict mode.  To be honest, if
a web author wants to change the border in quirks mode they just have to add
!important to thier css file.

Comment 24

[bora123]

After reading the James's intersting suggestion, I decided not to persue this 
bug anymore. Whatever you put in the quirks.css, it is ok. I think it is 
useless to get into argument for a 'simple it is' fix. If you think 
'!important' should remain there, well all righty then.

signing off/

Comment 25

[James Lariviere]

Rod from your earlier comments...

In fact, if people really want, I can even remove the "! important" on the text 
control in quirks, reopen the original bug and mark it "Won't Fix".

This would enable the greatest flexibility for web developers as they move their
content from pre-HTML 4.x markup to strict mark up. 

I think either one would be better than the way mozilla renders today.

IMHO, I think that adding your new rule to include all form elements is the
"best" option.  Then if anyone tries to change the border style for any form
element in quirks mode it will not work in any element not just text's.

Would you reconsider this for mozilla0.9? thanks :-)

Comment 26

[Ian Wehrman]

i can confirm this on linux 2001040821, probably should be marked OS = ALL.

Comment 27

[Vicente Salvador]

OK, we want to be compatible with NS4 in quirks mode, so by default text inputs
should be LIKE in NS4 but if a programmer would like to use the advanced
features of MOZILLA, Why not?

I think the textarea aproach is better. By default, like NS4 but I can use style
properties to change the appearance.

Please triage this bug again and put it on some target milestone like 0.9.2 ;-).
This is simple to patch because we must to take out the !important on the file
res/quirks.css

/* Quirk: text input has fixed look in compat mode (b=25580) */
input[type="text"] {
  border: 2px inset ! important;
  padding: 1px 0 0 0;
} 

Comment 28

[rods (gone)]

Final patch:
Index: quirk.css
===================================================================
RCS file: /cvsroot/mozilla/layout/html/document/src/quirk.css,v
retrieving revision 1.18
diff -u -r1.18 quirk.css
--- quirk.css   2001/05/18 23:09:54     1.18
+++ quirk.css   2001/05/30 15:14:59
@@ -91,7 +91,7 @@

 /* Quirk: text input has fixed look in compat mode (b=25580) */
 input[type="text"] {
-  border: 2px inset ! important;
+  border: 2px inset;
   padding: 1px 0 0 0;
 }

Comment 29

[Kevin McCluskey (gone)]

r=[e-mail]

Comment 30

[Marc Attinasi]

sr=attinasi for patch in Comments From [e-mail] 2001-05-30 08:17

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does setting the 'border' property now (with this fix) have a sensible result,
or does this just cause the problems described in bug 25580?  (i.e., has the
sizing algorithm been fixed so it doesn't assume a 2px border?)  I'd rather see
the style ignored than do the wrong thing.

Judging from the comments above, it probably does do the right thing, although
that's not completely clear, so...

a=dbaron for trunk checkin

Comment 32

[Simon Fraser [no longer active]]

Does this affect bug 83173?

Comment 33

[rods (gone)]

I don't think this has anything to do with 83173.

Reopening and marking bug 25580 as "Won't Fix"

Comment 34

[rods (gone)]

fixed

Comment 35

[Chris Petersen]

Marking verified in the June 27th build.