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.

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

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.

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

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

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

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; }

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

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

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

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

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

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

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

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.

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?

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.

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.

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 */

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

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.

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/

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

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

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; }

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; }

sr=attinasi for patch in Comments From rods@netscape.com 2001-05-30 08:17

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

Does this affect bug 83173?

I don't think this has anything to do with 83173. Reopening and marking bug 25580 as "Won't Fix"

fixed

Marking verified in the June 27th build.