If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

cannot override forms.css' select border width and style (set to !important)

RESOLVED FIXED

Status

()

Core
Layout: Form Controls
--
minor
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: Andrew Keyser, Assigned: mats)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040520 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040520 Firefox/0.8.0+

Forms.css forces the select element to have 2px inset borders, whereas every
other element is not forced.

Reproducible: Always
Steps to Reproduce:
1. try to change the select, input, and textarea element's borders in
userContent.css
2. Test on this bug page (look at the select elements at the top)
3. This time modify the userContent.css to make it !important
4. Test again
Actual Results:  
Both tests left the select element with 2px inset borders, but everything else
worked. The DOM inspector reveals that forms.css, which apparently for some
reason overrides userContent.css, has those 2 rules !important. 


Expected Results:  
The border style and width should change.

I don't know why forms.css does this. It doesn't make sense; why allow
everything EXCEPT select elements to be changed!? Shouldn't the !important be
removed? 
If not, I want a valid explanation - I want to make all my form elements on
bugzilla look the same for god's sakes!
This could also apply to radio and checkboxes but I know that's been discussed
before...

Marking normal because a regular end user would not know to, much less HOW to,
change res/forms.css to allow this...
> I don't know why forms.css does this. 

See bug 94387.

Unless you can suggest a different fix for that bug, this is wontfix...
(Reporter)

Comment 2

14 years ago
That bug is now invalid... I don't see why Mozilla needed to do anything for
that case anyway, it was a Juno bug, not Mozilla...

As far as I'm concerned, the moz-dropdown can stay important (because that's
something that has been like that forever...) but the select should not be
important. I use CSS to customize the borders on text inputs, so why deny the
ability to do it on selects? I don't really have too much to back myself up here
except for a little common sense... 

Comment 3

13 years ago
Thanks for posting this bug, i've been getting a little bit irate about firefox
not accepting my borders, checkboxes, selects all look a bit weird when
everything else is using 
border:1px solid black and border:1px solid blue on focus.

Why do the options need to be !important? 
like, when someone overrides them do they not really want them to be overridden?

I think !important should be removed from all color, border, font styles in
forms.css.
And possibly linespacing (those people with bad site who like wide line spacing
must be getting a bit anoyed by now) 
and images  (why shouldn't I  be able style the image on a combobox?)

Comment 4

13 years ago
Created attachment 156245 [details]
forms css without !important borders/colours

I've removed most of the importants from forms.css, this has no effect on sites
that don't override the style of form elements, but allows sites that wish to
override form elements to be able to.

Comment 5

13 years ago
I would like to see this bug fixed also. It annoyed me so much to have mozilla
disrespect my stylesheets. About bug 94387, it seemed that it was a little
precipated, the bug was promptly fixed just to render a single webpage that is
not even on the top show-stopper sites. And now the bug doesn't even make sense,
since the site changed and it doesn't have anymore reports of similar css uses.
IMHO, bug 94387 should have been fixed with a suggestion to add that rule to
USERS stylesheet, just for those that really wanted to see juno.com that way,
not to the BROWSERS stylesheet.

Again, it doesn't make sense to let input and buttons be customized, but not
selects. And since it is on browsers stylesheet and with !important, there is no
workaround to this issue.
(Assignee)

Comment 6

13 years ago
Created attachment 158799 [details] [diff] [review]
Patch rev. 1
(Assignee)

Updated

13 years ago
Attachment #158799 - Flags: superreview?(bzbarsky)
Attachment #158799 - Flags: review?(bzbarsky)
(Reporter)

Comment 7

13 years ago
I think it would be a good idea to do the same thing to the radio button, and
all the other controls as well, for the sake of taking care of it sooner than
later. Quite trivial really. I would do it myself but it happens that I'm in
windows right now and my mozilla source tree is on my linux partition.
> whereas every other element is not forced

As pointed out later in this bug, that's false.

Mats, what sort of testing have you done on this patch?  Does it affect how
border styles on <select> apply to the dropdown (the part that pops up), as I
would expect based on bug 94387?  I'm pretty opposed to applying border styles
to the dropdown, no matter what, so if this patch allows that we need to do
something different.

Also note bug 253690 with similar discussion and a near-identical patch (which
has the same testing-required issues).
Blocks: 253690
(Assignee)

Comment 9

13 years ago
(In reply to comment #8)
> Mats, what sort of testing have you done on this patch?

I copied resource:///res/samples/test8.html and added a
<style>select {border: 5px dashed red;}</style> to it -
I didn't see any problems.

> Does it affect how border styles on <select> apply to the dropdown

No.

> ... as I would expect based on bug 94387?

That part of the fix for bug 94387 is unnecessary to fix what used
to be the problem at http://www.juno.com (select{border:0}).
(Assignee)

Comment 10

13 years ago
(In reply to comment #7)
> I think it would be a good idea to do the same thing to the radio button,
> and all the other controls as well

I'm not sure that is a good idea. The difference with <select> is that it
is easy to recognise it as a select form element even when its border is
styled, whereas that is not the case for some of the other form controls.
(E.g. input[type="radio"],input[type="checkbox"]{border:0;})
Some form elements behave strangely when changing the border-width only.
(E.g. input[type="checkbox"]{border:10px;})

I have looked through the remaining "!important" in forms.css and I
didn't see any more I wanted to remove.

(Except for input[type="file"]{border-style:none!important;} but I have
little hope that will be accepted ;-)
(Reporter)

Comment 11

13 years ago
I beleive that all controls you mentioned should be styleable, because website
designers like myself to this point have not been able to style them and I feel
that with these unlocked it would open up new design capabilities in websites.
It's up to the designer whether or not the radio button or other control looks
right with different borders - that's not really the browser's responsibility
(except maybe the radius rendering code could be made more accurate). Again, I
don't really have much to back my side up other than common sense - if we
already have CSS being used to style them, why not allow the designers to
actually make use of it?
> It's up to the designer whether or not the radio button or other control looks
> right

Except browsers handle border styles on these differently, and 99% of "web
designers" never test in anything but IE.

Mats, I'm a little confused.  Bug 94387 was about the dropdown having no border
when border was set to 0 (or "none") on "select", right?  Given that, why does
simply setting style on -moz-dropdown-list help?

(Reporter)

Comment 13

13 years ago
In the two main controls I'm talking about, the radio and checkbox, no one ever
tries to style them in IE because they _can't_ style them in IE. So I don't see
any problem there. The only way they might become messed up in Firefox without
the designer knowing is if they make a whopping big typo.
(In reply to comment #13)
> In the two main controls I'm talking about, the radio and checkbox, no one
> ever tries to style them in IE because they _can't_ style them in IE.

Sorry, that's not true.  Please look up the bugs on styling of those controls
(eg styling of backgrounds for them, as well as the bug that added the
!important on the borders).

> So I don't see any problem there.

That's because you're trying very hard not to see the problems.  We don't have
such a luxury, unfortunately.
(Reporter)

Comment 15

13 years ago
I'm a little rusty on my knowing of features (?) of IE, but I don't think you
can style them with CSS. 
However now that I look into this situation I can see that a problem might arise
when someone makes a general "input { border: none }" declaration that would
apply to both the checkbox and the radio and all other controls living under the
input element... I stand corrected. I do see now why it isn't the best to
un-!important those because that will create a lot of problems with those
controls on designs that use similar methods. Sorry about that.. I wasn't quite
thinking of the technical details at the time. So in that case I guess that the
current patch would be fine, it's better than nothing.
(Assignee)

Comment 16

13 years ago
(In reply to comment #12)
> Bug 94387 was about the dropdown having no border ... right?

I don't see any evidence that bug 94387 was about the dropdown _menu_.
It's just the reporter who refers to the <select> element as a "pulldown".
Bug 94387 comment 9 indicates it's about the form element as such.

Anyway, I downloaded Mozilla 0.9.1 (its UA stylesheet set borders without
"!important") and indeed it's the border around the <select> that's missing -
the border around the dropdown menu isn't affected by the author
"select{border:0px}" rule.
Comment on attachment 158799 [details] [diff] [review]
Patch rev. 1

OK, in that case r+sr=bzbarsky (with a heavy heart)
Attachment #158799 - Flags: superreview?(bzbarsky)
Attachment #158799 - Flags: superreview+
Attachment #158799 - Flags: review?(bzbarsky)
Attachment #158799 - Flags: review+
(Assignee)

Updated

13 years ago
Assignee: nobody → mats.palmgren
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
(Assignee)

Comment 18

13 years ago
Checked in 2004-09-15 14:17 PDT

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

13 years ago
Blocks: 53590
(Assignee)

Updated

13 years ago
No longer blocks: 53590
You need to log in before you can comment on or make changes to this bug.