459034 - forms.css checkbox and radio controls rules makes it impossible to overwrite them

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Oskar Eisemuth]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

The layout forms.css file uses a lot !important rules for checkbox and radio controls. Styles can't be overwritten by Webpages neither by User css.

Reproducible: Always

Steps to Reproduce:
input[type="checkbox"] {
	-moz-appearance: none;
	border: 1px solid black;
}
Actual Results:  
The border isn't changed as form.css uses !important.
Partly access to the border is allowed via -moz-border-*-colors.

Expected Results:  
A black border, as in Opera, other css should be usable too, background-color, color ... 

The !important rules are introduced for broken webpages. Native controls are used via -moz-appearance so there isn't anymore a point to fix broken pages via forms.css

As soon -moz-appearance is set to none, let the webpage change the style for the web controls as Opera/Webkit does. A automatic switch to -moz-appearance none would be desirable but Webkit uses -khtml-appearance, so setting -moz-appearance: none; is a good enough measurement if the webpage author tests for Gecko compatibility...

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is done on purpose, as you note.  Please actually read the bugs on this and note that making the changes you propose will re-break the so-called "broken" web-pages.

> A automatic switch to -moz-appearance none would be desirable

This already happens, of course, as soon as the author styles one of the relevant properties.  If they're not !important, that is.

I strongly urge you to take up the issue of form control styling with the CSS WG.  The current situation, where it's completely undefined, is not so great.

Comment 2

[Oskar Eisemuth]

(In reply to comment #1)
> This is done on purpose, as you note.  Please actually read the bugs on this
> and note that making the changes you propose will re-break the so-called
> "broken" web-pages.
Yes, as I understand these bugs only when -moz-appearance: none would be set in the css or the platform wouldn't support native controls for them.

> > A automatic switch to -moz-appearance none would be desirable
> 
> This already happens, of course, as soon as the author styles one of the
> relevant properties.  If they're not !important, that is.
Sorry, since when does that happen? 
I couldn't force the switch to build-in controls via css width... 
Tested with Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b1pre) Gecko/2008092900 SUSE/3.1a-12.2 Minefield/3.1b1pre too, I guess I miss something here. 

Note: Other input elements do switch of course, but not a checkbox...

> I strongly urge you to take up the issue of form control styling with the CSS
> WG.  The current situation, where it's completely undefined, is not so great.
So this would be a feature request to get some -moz-*-checkbox styles to fully style a checkbox and radio control without breaking old pages until CSS official supports this in a sane way.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> as I understand these bugs only when -moz-appearance: none would be set in the
> css

You understand wrong, then.

> I couldn't force the switch to build-in controls via css width... 

The switch happens on setting borders, backgrounds or padding, since those are the things that native rendering handles.  Again, you'd have to remove the !important rules for some of those (which is why we can't really remove them).  Or try background-image on a checkbox, for the same effect.

> to fully style a checkbox and radio control

It's not even clear what that means.  For example, what's the "border" of a radio?  Is it the round thing, or is it something outside that?  We're not going to start changing behavior here until there is basic agreement on what the right behavior is amongst the various UAs.  Hence my comments about the W3C.