106317 - [CBX]can not style select border

Status: RESOLVED FIXED

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

Description

[James Lariviere]

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.

Comment 1

[James Lariviere]

Attachment: testcase -- normal, :hover and :focus

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[James Lariviere]

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>

Comment 4

[Jesse Houwing]

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

Comment 5

[rods (gone)]

We currently are preventing this on purpose.

The spec really isn't clear about styling form controls, it is being addressed 
in CSS3 spec

Comment 6

[Danny]

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.

Comment 7

[rods (gone)]

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

Comment 8

[Danny]

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

Comment 9

[Jesse Houwing]

Calling in [e-mail]

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?

Comment 10

[Jesse Houwing]

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.

Comment 11

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

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 14

[Robert Clark]

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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Chris Casciano]

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.

Comment 17

[fantasai]

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

Comment 18

[Karsten Bräckelmann]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Karsten Bräckelmann]

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

Comment 21

[Robert Clark]

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?

Comment 22

[Dan Allen]

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.

Comment 23

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

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.

Comment 24

[fantasai]

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.

Comment 25

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

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.

Comment 26

[James Lariviere]

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

Comment 27

[Nik Makepeace]

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.

Comment 28

[Chris Casciano]

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.

Comment 29

[fantasai]

Attachment: proposed patch

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

Comment 30

[Jesse Houwing]

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.

Comment 31

[fantasai]

[e-mail], dbaron -- Would you please review?

Comment 32

[James Lariviere]

[e-mail] 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.

Comment 33

[fantasai]

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 34

[fantasai]

Attachment: patch v2

Comment 35

[fantasai]

Comment on attachment 69338 [details] [diff] [review]
patch v2

Causes problems in chrome

Comment 36

[fantasai]

Attachment: patch v3

New patch (v3)

Comment 37

[fantasai]

Attachment: the real patch v3

Attached the wrong file.. ¬_¬

Comment 38

[rods (gone)]

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

Comment 39

[fantasai]

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 40

[rods (gone)]

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

r=rods

Comment 41

[Flo Ledermann]

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.

Comment 42

[Boris Zbarsky [:bzbarsky]]

Flo, have you ever read the proposed patch?

Comment 43

[Karsten Bräckelmann]

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.

Comment 44

[Boris Zbarsky [:bzbarsky]]

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.

Comment 45

[Jesse Houwing]

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.

Comment 46

[Boris Zbarsky [:bzbarsky]]

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

Comment 47

[David Hyatt]

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.

Comment 48

[fantasai]

Attachment: patch v3a

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.

Comment 49

[fantasai]

Attachment: patch v3.1a

forgot to delete namespace

Comment 50

[fantasai]

Attachment: patch v3.2a , hopefully w/out mistakes

Comment 51

[David Hyatt]

sr=hyatt

Comment 52

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

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)

Comment 53

[fantasai]

Attachment: patch v3, updated context

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

Comment 54

[fantasai]

Comment on attachment 76947 [details] [diff] [review]
patch v3, updated context

transferring r/sr/a since no code has changed

Comment 55

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 56

[Henrik Gemal]

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

Comment 57

[mozilla]

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.

Comment 58

[fantasai]

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.

Comment 59

[James Lariviere]

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.

Comment 60

[mozilla]

Attachment: Comparison of borders w/ and w/o stylesheet in Mozilla and Netscape

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.

Comment 61

[Juliano F. Ravasi]

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.

Comment 62

[Boris Zbarsky [:bzbarsky]]

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