While working on a Halloween style theme I noticed that the current win builds (10-22-2001--03) do not allow you to style the select (sigle and multiple line) html form control. This is a regression. Not sure how long ago (maybe since the big style changes). Will provide screenshot and testcase shortly and check to see if this happens on linux too.

forms.css has: border: 2px inset ThreeDFace !important; This was put in to fix bug 94387. You will be seeing the problem you are seeing on Linux as well... This is basically by design. :(

God that means any site that styles form controls will be penalized for one sites crappy and thoughtlessly written css. Hmmm... maybe I should write 0px borders for input[type=text] to get that one adjusted too. This is a slippery slope. <SoapBox> I have to say that bug 94387 fix is lame and should be backed out. If mozilla breaks css styling form elements, it should be for ALL html form elements and not just for one here and there. There should be some sort of discussion on how to fix (or agreement) reached for all html form controls. Stylable or Not Stylable. :-) </SoapBox>

You can fix this for now by adding !important to your own styke rule :)

We currently are preventing this on purpose. The spec really isn't clear about styling form controls, it is being addressed in CSS3 spec

The design of juno.com has changed, which makes the fix for bug 94387 irrelevant. Netscape 6.0 through 6.2, as well as other Gecko based browsers, were shipped with the ability to style <select> borders. Taking this out and breaking CSS1 conformance is likely to cause more pain to the web authors than solving the problems.

See we aren't breaking CSS1 conformance, because its CSS3 that will be specifying how form controls should be styled.

So disregarding CSS1... 1. What problem is disabling <select> border style trying to solve? 2. What about the existing web designs that works in Netscape 6 and previous Mozilla releases, but not in later Mozilla release? 3. As for W3C not specifying how to style form control elements, shouldn't the styles for *all* form control elements be disabled? It just seems bizzare to me that there's a special case for "<select> border" which cannot be styled by the web author. I shiver whenever I write special cases in my program. :-)

Calling in fantasai@escape.com Since his bug 43220 checked in the workaround with !important also stopped working. Also I agree with the fact taht if borders of selects are disabled because the definition isn't clear then the border for: * checkboxes * radiobuttons * inputs should also be disabled. But then why do that IE supports those since 4.0 so does Opera, so why won't mozilla allow styling them?

To add to my previous comment. It is my opinion that it SHOULD be able to style ALL form elements, or none. Currently is you set a border on a radiobutton it appears as a circle. In Internet Explorer it appears as a box around a normal radiobutton (very ugly). So should we also disable a border on radiobuttons? So I want to suggest to fix this by removing the !important from froms.css and make all the form elements equal. Or fix the border on all form elements but not a half way solution that is checked in now.

This is not a bug according to CSS. Since the CSS rendering model does not describe how CSS styles apply to form controls, any application of styles to form controls is an extension of CSS and we need not support it (and I think we should not unless we develop a very clear plan for what the styles should mean).

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

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

I think this is a real shame - One of things Mozilla has going for it from a designer's point of view is it's flexibility. I don't think this should be restricted because one site used to not quite look the same in mozilla as it did in IE. Since the CSS1 & CSS2 specs don't make it clear what the borders on form elements should refer to, allowing borders won't harm standards support. The current working draft for CSS3 user interfaces includes an updated default stylesheet (http://www.w3.org/TR/css3-userint#qA) which sets border properties on selects (among other form elements) to match the system defaults, so I think we can be pretty sure that stylesheets making use of this will work fine under CSS3. I'd advocate removing the !important completely from the "border: 2px inset ThreeDFace !important;" in forms.css. If preventing authors from setting "border: 0px" is !important, though, how about the following compromise: border-width: 2px !important; border-style: inset; border-color: ThreeDFace; At least we can then change the colour of select's borders.

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

To echo some other comments here I'd just like to say that supporting styles on /some/ form elements and not others is a big problem. The particular problem that brought me to this bug today was because I wanted to style a "jump navigation" type element consisting of a select next to a submit button. If I set the same border on both elements the look perfectly fine next to each other in IE 5.1/ OSX, Opera5b/OSX & Opera 6/PC (all with the borders) and NN4, icab & omniweb (without the borders on either). The mismatched look of the elements that are presented in mozilla however have cause me to scrap the whole thing. And please folks, drop the W3C crutch on this one. If, in Moz 0.9.7, you can set a background color on a SELECT, if you can set a border on a OPTION, then to me this can be considered nothing *but* a bug.

I'd go with Robert Clark's solution. However, for consistency, the !important border-width should also be set on some coherent group of other form fields. input:not([type]), input[type="text"], textarea, select /* inset text */ -or- input, textarea, select, submit, button /* all form fields */ Any preferences? >his her

I really think, *all* form elements should be *completely* stylable. I stumbled across the non-stylable border of select-elements some weeks ago and considered it a temporarily bug... IMHO it could be very useful, if web-designers have the freedom to style their form elements like some (Win) GUIs do it for years. It is definitely the wrong way to allow only some elements to be styled. Even the border-width is relevant. Following CSS should present a fully flat select box: select { border: 1px solid #000000; } In addition the small arrow-button should behave as expected: the same border as the select-element and an 'inverted' border for 3D styles (as the default).

> I really think, *all* form elements should be *completely* stylable. As soon as CSS can actually be used to express the look of form elements, sure. Right now it cannot. For example, how does one go about styling an <input type="file">? How do you even know what it looks like? (the textbox-and-button impl is not the only possible one). In some browsers, (eg text-only ones) a <select> is shown as a bunch of checkboxes or radio buttons...

> For example, how does one go about styling an <input type="file">? Should be just as I described for the select form-element IMHO. We got a textbox and a button -- like the select element. The select element is way more often used, than a file-upload... > How do you even know what it looks like? (the textbox-and-button > impl is not the only possible one). But that it is the only implementation in Mozilla, or am I missing something? Slightly confused... > In some browsers, (eg text-only ones) a <select> is shown as a bunch of > checkboxes or radio buttons... We dont need any borders in text-only browsers... ;)

The file INPUT element is probably not a good example. The current CSS3 working draft specifically excludes it: http://www.w3.org/TR/2000/WD-css3-userint-20000216.html#scope meaning it's up to us to interpret its CSS properties in the light of how we intend to render it. The WD does addresses the various possibilities for rendering a SELECT, however. Anyone with the bits to do it want to add a css3 keyword?

take off that stupid !important directive in forms.css, it is just ridiculous. Every other form on my page follows my styles and then dump select boxes are all ThreeDFace...who cares about CSS3 right now if we can't use it, just make it consistent for CSS1 until you change every style. I have to keep going into my forms.css file when I install and delete that dumb directive.

IMO, any application of styles to form controls is an extensions of CSS, since form controls can't be described by the CSS formatting model. Furthermore, it's unlikely to be interoperable, and even less likely to be consistent with the way CSS works elsewhere. While many web authors who want "control" want form controls to be completely stylable, many users prefer native form controls. I think we're better off moving towards native form controls than stylable ones.

You're missing the point, David. The bug's not open because form controls aren't styleable, but because aribrarily, some are, and some aren't.

No, I'm not missing the point. I'm saying that we should fix the ones that are stylable. That's the opposite of the position advocated by comment 22.

Hey David I agree with you that we should make it consistant for all form controls even if it means no styles at all for form controls :-( BTW: I noticed that in the IE6 XP version (not sure for win98?) there is an advanced settings override option for author form controls styles and just render native XP controls (maybe an option for mozilla...)

It seems to me that we have here a conflict between the "total control at any cost" school of web design and the "Please don't let the browser wars happen again" philosophy of standards compliance. We can either * disable all box model styling on all form widgets (the Right Thing, given that we have no firm instruction on how to do so yet) * allow styling on all form controls (make it up according to a CSS3 WD, much as was done < 0.9.4, risking a problem when w3c change the rec) * maintain the current inconsistent and frustrating state of affairs (the Worst Thing) I strongly think that the final option is utterly unacceptable, even if it's the same as IE/Win. Option 2 has the political advantage that it encourages CSS use, showcases the power of Mozilla etc etc and makes the "total control" freaks happy, which in turn encourages a consideration of Mozilla during design. However, it rankles, because this kind of thinking has been very damaging in the past... Option 1, finally, is probably the WaSP fanatic's favourite, but don't let that put you off ;-) Until we have a concrete idea of how to apply styles to form controls, we should not attempt to guess.

I find some of the reasoning here a bit concerning. Myself, I am not a "total control freak" I'm just looking for something reasonable - which I believe this request is. Reverting *all* styles, while I agree may be the "proper" thing to do would cause havok. As mentioned in my earlier comment IE5/Mac and Opera (and formerly moz as well) currently handle styling of the select control, and IE/PC handles a good deal of styling as well (border on select just happens to be one it doesn't). So regardless of the spec developers will be using these properties. But if you were to choose to do that you'd be making a big stand based on your belief. You'd have to be consistant and complete in your removal of features. If something is not clear based on the CSS1 spec and not clarified in CSS2 (don't forget we're ignoring css3 cause its might still change) you'd have to drop support for it all together rather then interprit it. And I'd argue that this would also extened into other areas of support including HTML and the DOM (innerHTML?). Back on the "control" point. As a web developer I completely fall on the side of CSS acting as a suggestion to the user agent on how to display my content. It has every right to do with it as it pleases. I also believe the user has every right to allow or deny the subset of those 'suggestions' that the browser understands as he or she sees fit. But in this particular forum we are talking specifically about the development of the user agent. Myself, I would hope that the dev team chooses to build a user agent that allows styling of form controls in a manner similar to the other UAs mentioned. I'd also hope that they'd do it in a way where folks who prefer unstyled controls can choose to see them that way.

I reorganized some other rules as well, for consistency. -moz properties come after regular ones, and !important rules come last

I guess it's best when all have the same style, but still I think it should be up to the user to choose. I've already made use of the border styles in many sites. IE shows them for text-boxes, textareas and password fields, but does a very strange job on showing them on checkboxes and radiobuttons. I'd love to have the ability to set borders on all input fields myself, and if the user want's to take the chance, then why should they not be able to see it. I'm not sure if anybody already posted a bug to make this a pref. If not, then I'll do so.

rods@netscape.com, dbaron -- Would you please review?

fantasai@escape.com thanks for the patch. :-) I tested it out and I think it fixes the inconsistant rendering problems I reported. My only suggestion would be to group a little differently where there is not as much a priority placed on !important rules. Rather a more natural grouping like this for example (from your patch): textarea { margin: 1px 0 1px 0; - border-color: ThreeDFace; background-color: -moz-Field; color: -moz-FieldText; font: medium -moz-fixed; text-align: start; vertical-align: text-bottom; cursor: text; + border-color: ThreeDFace; + border-width: 2px !important; + border-style: inset !important; -moz-box-sizing: border-box; -moz-user-focus: normal; -moz-binding: url("resource:///res/builtin/platformHTMLBindings.xml#textAreas"); - border-width: 2px !important; - border-style: inset !important; -moz-border-radius: 0 !important; } I think that this way all the border stuff is together. This makes it easier to read. Other examples could be font, padding, margin, etc... where you keep those together. Again thanks for the patch.

I decided it was more critical to group !important rules together somewhere noticeable so that they don't get lost among other properties. As for the order of the properties, I first listed those which affect the box's type, position, and size, then transitioned through the border properties into fonts, then other text properties, then through text-align to vertical-align and finally, miscellaneous (i.e. cursors). I then put content last because it stands out there and the top is taken. Like this: display width height margin padding border-width border-style (sometimes affects width) border-color color (affects font ->) font white-space <other text properties would go here> text-align vertical-align miscellaneous content mozilla proprietary !important (same as above) I perhaps should have added an extra newline between the regular and !important rules. I'll do that now.

Comment on attachment 69338 [details] [diff] [review] patch v2 Causes problems in chrome

New patch (v3)

Attached the wrong file.. ¬_¬

I don't get the "xul" rules or namespace. This stylesheet is only used inside the content area where XUL will never be.

AFAIK, forms.css acts like a regular UA sheet--that is, it gets loaded with every page, just like html.css and xul.css. Most of the rules don't apply to the chrome because the selectors are in the XHTML namespace and chrome is written in XUL. However, the XBL bindings for <textbox> insert an HTML <input> (or <textarea>) element; thus the rules in forms.css affect these elements. Without the XUL rules, inset boxes appear inside <textbox>. You can apply patch v2 and open up the find dialog, if you want to see for yourself.

Comment on attachment 70066 [details] [diff] [review] the real patch v3 r=rods

this is totally ridiculous... to dbaron et al i propose the following: take out stylability of all form controls and watch the uproar among users... and then explain to them "well we don't have an exact spec for that and there has (once upon a time) been one page that looked different than in ie" - come on! the only acceptable, consistent solution is to do our best now (and that is: throw out the !important rule) and try to follow the emerging css3 spec as soon as possible. USERS can always put the !important rules in their userContent.css, VENDORS (did i say netscape?) can always put the !important rules in whatever.css but web authors can't. if anybody has time, make a preference (hehe) for "conservative rendering of form controls" and see how many users want it.

Flo, have you ever read the proposed patch?

I read the patch -- but I cant see, how that would help. Most of the changes are just sorting. I dont see !important rules cut out of forms.css. How is that supposed to solve this topic? Select borders are still not stylable.

Select borders are more stylable. The heart of the patch is: - border: 2px inset ThreeDFace !important; + border-width: 2px !important; + border-style: inset !important; + -moz-border-radius: 0 !important; This means that you can change the color of the borders. You just can't change the width or style. Furthermore, this is now the case for _all_ form controls with this patch. So our behavior becomes consistent -- you can change the border colors but not the widths or styles.

But everything WAS behaving the same before the patch for bug 94387 (see comment 3 and comment 4). So why break it even more. Out of all the websites out there, there's one that doesn't get it. And even that person has already fixed it by doing a restyle of their site. I still don't get it why we should NOT make all facets of form elements stylable as it was.

> I still don't get it why we should NOT make all facets of form elements > stylable as it was. Because it wasn't. For example, <select> and <input type="file"> controls had severe styling issues. One could do things like make <input type="radio"> controls completely invisible by changing their border width (as a note, that does nothing in IE, and yes there are pages which do things like "input {border-width:0}" and hence have invisible radio buttons). The point is, there is a tradeoff here between letting web designers style things, having those styles be consistent with the things they _can't_ style, and having to fix bugs that only appear when certain odd styles are applied. In the interests of saving effort that is better directed elsewhere and pending the CSS3 description of what styles _do_ apply to form elements and how, the patch in this bug makes perfect sense as a decent compromise.

Rules like: +:not(xul|textbox) > input:not([type]), +:not(xul|textbox) > input[type="text"], +:not(xul|textbox) > input[type="password"] { + border-width: 2px !important; + border-style: inset !important; + -moz-border-radius: 0 !important; are inefficient, resulting in all input fields having to check their parents in order to see if they're in a XUL textbox or not. forms.css should not have to know about XUL or contain style rules that reference XUL. You should just fix things over in the XUL stylesheets for textboxes.

The thing I don't like about this version is that it lets authors skip the !important rules by setting the class attribute. This workaround causes two problems: first, input styles are not restricted by the !important rule, and second, authors using it would be coding to Mozilla, which is a bad practice we shouldn't encourage.

forgot to delete namespace

sr=hyatt

Comment on attachment 70066 [details] [diff] [review] the real patch v3 a=dbaron for trunk checkin (assuming hyatt meant his sr= for this patch, as fantasai says)

The only difference should be on line 155 of the patch, to account for bryner's March 6th :checked checkin.

Comment on attachment 76947 [details] [diff] [review] patch v3, updated context transferring r/sr/a since no code has changed

attachment 76947 [details] [diff] [review] checked in to the trunk 03/31/2002 06:24.

It's such a shame that all left bottom corners in Mozilla suffers from bug: http://bugzilla.mozilla.org/show_bug.cgi?id=133489

Just to clarify, the latest build now reflects the proper application of border: 1px solid #BE9DBE to text fields (see Bug 134927). But the select fields remain Mozilla default notwithstanding CSS instructions otherwise. I have even tried my own !important rules, individually spelling out each element: (border-width: 1px !important; border-style: solid !important; border-color: #BE9DBE !important;) but the select boxes remain Mozilla default (see www.shepherdstown.com). At the very least, I expect, per comment #44 to be able to "change the color of the borders. You just can't change the width or style." If the color is changing, I am not seeing it. Beyond the border-color, is it the intention to permit styling of <select> prior to the release of Moz1.0 (or at any point prior to CSS3)? If not, please explain how can I implement the workaround referenced in #48 in order to implement this functionality.

You should be able to change the colors. The 2002040708 build works as expected with the, IMO very excellent, testcase provided by James Lariviere as well as on www.shepherdstown.com. I see no reason why it shouldn't still work. From current lxr: 132 border-width: 2px !important; 133 border-style: inset !important; 134 -moz-border-radius: 0 !important; Border-color doesn't have !important. Could you please attach a screenshot showing the problem? > workaround referenced in #48 The workaround in comment #48 does not apply to selects, and in any case, that particular patch was not checked in so it's completely irrelevant.

I'm marking this fixed again because looking at (www.shepherdstown.com) and testcase (attachment 54765 [details]) the border-color renders as expected. Although there is some wierd renderings when you click into one of the text inputs or the multi-lined select (text cursor displays next to its label and the multiple select renders offline). Does anyone see this (winXP 2002-04-08-03)? I'll post a screenshot.

Attach is a graphic which shows a side by side comparison of <select> in Mozilla (4/10/2002 build) with and without border attributes and in Netscape 6.2.2. These demonstrate that, yes, a border-color is applied but that: 1.) the 3D overlay results in colors which are markedly different from the base color (which ruins the designer's intended subtlety in the color scheme); 2.) when the 3D effect is applied, the top and left corners of the widget are all but invisible on many displays (particularly on LCDs). However, the border color (as seen in the <input> field) remains visible even on those displays so it is not an issue with the border color v. the background color. Therefore, it appears that the issue lies with override of border-width and border-style with the Mozilla default. I fail to understand why border-width/border-style were removed when: a.) they worked well in earlier versions of Mozilla and the current version of Netscape (6.2.2); b.) they are supported by competing browsers; c.) CSS2 does not prohibit their application; no new extensions are otherwise created; and CSS3 is anticipated to explicitly support this; d.) certain form widgets like <input type="text"> support it without an issue (see the partial backing out of this patch)--why are such fundamentally different? e.) implementation of border-color but not border-width and border-style can reduce the visibility of much of the widget in low contrast colors. f.) the feature apparently can be easily reinstated by removing the !importants and thus make the 1.0 release with little effect elsewhere.

Just to leave a note: I'm just another annoyed user who was hit by this bug. Precisely, I wanted to customize border styles and widths for select elements, which was intentionally dropped. Too bad I arrieved here too late for the discussion (but it seemed that my opinion wouldn't be head anyway). What it looks to me: Mozilla was quite nice rendering select elements the way it did; someone just found a single page which didn't render like it was expected (because the webmaster told so), and filled bug 94387, which became invalid (the webmaster remodeled the site 3 months later) but was already fixed. Since the fix of #94387, many unhappy users filled many bugs about select not being customizable (#106317, #109120, #111132, #111190, #113336, #114631, #187691, #244370 and #253690) but no mozilla developer wants to actually back it up. The whole thing: one report about <select> being customizable and at least nine reports about it not being customizable after it was sabotaged. And mozilla actually have support for it in place, but it is just censored. If anyone knows a workaround, please tell me.

> just found a single page which didn't render like it was expected This is where you're wrong. A fairly large number of pages was being bitten by assumptions that form controls would be styled "the IE way" when Mozilla did something totally different. The <select> widget is not the only one whose styling was restricted, if you will note. Changing some of the others (eg radio buttons and checkboxes) is really not an option, and its preferable to have the form controls consistent amongst themselves as much as possible. > after it was sabotaged Strong words for what is after all a design decision about how CSS should "apply" to cases the CSS spec does not define. If you're willing to put in the effort to ensure that changing this decision does not cause undesirable consequences, please do so; arguments backed up with data will be listened to much more than plain ranting.