79719 - Interior of radio button should not be affected by background-color style

Status: RESOLVED FIXED

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

Description

[ortwin.glueck]

When a background-color style is specified with a radio button, the interior of
the button becomes also colored (and not only its surrounding area). In other
browsers the interior of the radio button is always white.

Sample:

<input type="Radio" name="Value_2" value="1" style="background-color:#F0F0F1">

Comment 1

[Boris Zbarsky [:bzbarsky]]

ccing mpt.  It seems to me that keeping the middle white no matter what is a bad
idea (seeing as the color of the little dot can be changed to white or something
like that).

Comment 2

[ortwin.glueck]

I assume nobody would ever want to change the color of the small dot inside the 
radio button. But most people want to integrate a radio button seamlessly into a 
colored background. What matters is compatibility to existing browsers. A page 
should display equally on all browsers in the end. So please stop making 
proprietary assumtions.

Comment 3

[Matthew T (active 1999-2002)]

Erm ... I don't know why I'm here, rather than dbaron or Hixie, but never mind.

Given that about a quarter of the W3C's CSS Working Group is made up of people 
who work on Mozilla, accusing us of making `proprietary assumptions' is amusing 
to say the least.

Are we making assumptions? Yes we are. If we weren't, we wouldn't apply style 
to HTML form controls *at all*, since the behavior of form controls with 
respect to CSS is not defined in any W3C specification. But are those 
assumptions proprietary? Of course not. Mozilla is open source, so we couldn't 
be proprietary even if we tried.

> A page should display equally on all browsers in the end.

That's a common myth, but its commonness doesn't make it any more correct. The 
fact that Mozilla's HTML form controls don't look like Aqua widgets on Mac OS 
X, or like BeOS widgets on BeOS, or like GTK widgets in GNOME, is a rather bad 
bug. And some of these widget sets don't *have* a dot in their radio buttons.

Currently, we draw radio buttons entirely in CSS. We use the
`-moz-border-radius' property to determine that they're round rather than 
square, we use the `border' property to draw their borders, and we use the 
`background' property to fill in the space inside the borders (since that's 
what a `background' is, in CSS).

That last detail is why changing the `background' property for a radio button 
will change the color inside the border, rather than outside. This is perfectly 
reasonable behavior, and it will remain the case until we get XBLified form 
controls -- whereupon form controls will probably be quite a bit less stylable 
than they are now. Resolving as invalid.

Comment 4

[Vladimir Ermakov]

Verifying invalid

Comment 5

[R.K.Aa.]

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

Comment 6

[R.K.Aa.]

bug 135134 is a sample of how the current radio buttons break skinability

Comment 7

[John Keiser (jkeiser)]

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

Comment 8

[John Keiser (jkeiser)]

The background color problem still occurs with XBL form controls.

There are two apparently opposing points here:

1. that the background color in the box the radio button *occupies* should be
styleable, and a border around it given.
2. that radio button background and color should somehow be styleable

Color (to change the interior of the form control) is not honored with XBL form
controls, so it actually makes *sense* not to be able to change the background
color either.  So #2 can arguably be stricken from the record.

#1 is more correct, too.  Everywhere else it is used, background-color in CSS
refers to the *box* an element occupies (this is the case for text elements, the
only other non-rectangular element I can think of).  IE is doing the right thing
here.

A potential solution to the problem is to have the visible radio button be
anonymous content under the radio button (this avoids having to do drawing
code), and the radio button itself be a simple box.  You could style the
anonymous content using something like "-moz-radio-background-color" and
"-moz-radio-color" if it ever came down to it.

Comment 9

[fantasai]

Confirming, since the described behavior does exist.

> Everywhere else it is used, background-color in CSS refers to the *box* an
> element occupies (this is the case for text elements, the only other
> non-rectangular element I can think of).

Background color on radio buttons *is* referring to the box the element 
occupies; we just curve the corners of the box (something you can do in CSS3).

> IE is doing the right thing here.

I disagree; I think the behavior of our radio buttons makes more sense.

Coloring radio buttons was brought up on www-style before--here's a post from
Tantek Celik: http://lists.w3.org/Archives/Public/www-style/2002Mar/0069.html
(You might find it significant that Tantek works on MacIE5's rendering engine.)

> You could style the anonymous content using something like "-moz-radio
Please, let's avoid adding unnecessary non-standard CSS code.

Comment 10

[R.K.Aa.]

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

Comment 11

[R.K.Aa.]

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

Comment 12

[R.K.Aa.]

the fix for bug 58755 has improved the situation some.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Indeed.  We've simply turned off background-color styling on radios altogether.

Comment 14

[Mike Holderness]

Spake Boris Zbarsky @ 2003-11-14 00:36 PDT:

> We've simply turned off background-color styling on radios altogether.

And, if it's not too much trouble, I'd like it back. 

I understand that there are philosophical points about CSS. 

I understand that in strict mode one of a collection of radio buttons must be
selected, and I deeply disagree with that: I've just amended
www.londonfreelance.org/rates/submit.html to ask for the submitter's gender, and
I definitely do not want a default gender and definitely am happy with quirks
mode behaviour. 

I would therefore like, pretty please, some consistent way visually to flag that
the question hasn't been answered. Aesthetically I'd prefer the "depths" of the
button to be coloured (a la Oper) but I'm not that bothered if the surround is
coloured (a la IE).

Comment 15

[Boris Zbarsky [:bzbarsky]]

> And, if it's not too much trouble,

Unfortunately, it is.  Please do read bug 58755 most carefully.