checked radio buttons css

I understand what you were trying to accomplish, and I probably should have offered an additional explanation.

While you really can do something like this:

input[type="radio"]:not(:checked) + label {
    color: #888;
}

input[type="radio"]:checked + label {
    color: #000;
}

it would be no different from:

input[type="radio"] + label {
    color: #888;
}

input[type="radio"]:checked + label {
    color: #000;
}

The :not(:checked) pseudo-class selector makes no difference between radios that haven't been checked before a user action (user clicking on one radio button) and the unchecked radios after a user has clicked one.

While CSS can be pushed, there are limits to what you can do. I'm afraid this is one of them. Even the general sibling combinator wouldn't work here:

input[type="radio"]:checked ~ input[type="radio"] + label {
    color: #888;
}

because it would only select the radio labels after the one that was selected. So basically, it would only work as planned if the user selected the first radio button.

It's fun to think about, though. If there was a combinator which would get all the siblings of an element, even the ones that come before it, then this could be done. Or, if there was a parent selector, allowing you to get the parent element of the checked radio, then it could also be done with CSS alone.

I haven't been following the CSS Selectors Level 4 draft recently, but I've heard mentions of parent selectors in there. Ah, I found it after a quick glance. With the current proposal, !E > F would select the E element which is the parent of a F element.

Until browsers implement support for such theoretical selectors, we're stuck with doing some JavaScript. :)

I think Dino is right with the all siblings selector.

Alex,

One thing that might help you is to realize that you can't detect state changes with css. A radio button is either checked, or it's not checked. It's in a certain state. There's no such thing as "the radio button was just checked", at least in css. You can't detect a change from one state to another.

Same idea with form elements. A form element either has focus or it doesn't. Can't detect that it "just received focus" or "just lost it".

For future reference,

There might be a way to do this with the :indeterminate psuedo-class

http://dev.w3.org/csswg/selectors4/#indeterminate

Hi Alex,

Changing the requirements to what you show in the pen does change the problem considerably. It went from a probably impossible css solution to a simple css solution. All it took was one selector and one property/value pair. The initial requirement of them all starting off black made it difficult.

The concept of state changes might make more sense to you if you think about what the jQuery solution would have been based on the original problem.

In jQuery we would have written an event handler for when a radio button was clicked. Inside the event handler we would have code that would change the colors of the two other radio buttons. To lightgray or white, whatever you were using.

In an event based system, you have events, and an event marks the moment when something changes from one state to another. An event handler let's us execute code in response to an event having just taken place. the moment you click on the radio button an event fires off and you're able to do something the moment that event takes place.

We do not have the equivalent of this in css. You can't detect the moment a state change takes place. It's in one state or the other. You can't do anything with the in between part.

Of course, with the new requirements, this limitation of css is no longer a problem for you.

I hope that makes more sense to you.