Comment 3 for bug 1211866

A *secondary control* is one that is on the same screen as another control, but is relevant only if that other control is checked or set to a particular value. For example, the various "Exceptions..." buttons in Firefox Preferences.

When they are not buttons (and even sometimes when they are), secondary controls are typically indented immediately under their primary control. For example, in "Time & Date" > "Clock" settings on Ubuntu for PC, "Include week numbers" is secondary to "Monthly calendar", so it is indented underneath.

When you need to make exactly one choice from a group of two or more, and one of those choices has secondary controls, it's generally neatest for that choice to be the last one, so that the top-level options are positioned close together. But sometimes you can't do that. When you can't, the secondary controls end up between two of the top-level options, so an ItemSelector doesn't work. And *that* is why you need radio buttons.

Sometimes the option with secondary controls can't go last because the order of the options matters. A current example is the "Location" settings, both in the first-run setup and in System Settings. The "Using GPS, anonymised Wi-Fi and mobile network info" option has a secondary control: a caption containing a hyperlink. It can't be the last option, because that would mean "Not at all" was the first option, which would wrongly suggest it was recommended. So it has to be first or second, which means that the secondary control has to be between two of the top-level options. In the first-run setup, this is currently faked with checkboxes, which is terrible because the checkboxes are unchecking each other. <http://www.nngroup.com/articles/checkboxes-vs-radio-buttons/> And System Settings currently uses an ItemSelector for the same options, which looks even worse, because the second item is distended and the part of it that isn't the hyperlink is a weird shape.

Other times, the option with secondary controls can't go last merely because there are two or more of them. A future example of this is proxy settings. The top-level choices are (A) no proxy, (B) auto-detect, (C) auto proxy configuration, and (D) manual configuration. Both C and D necessarily will have secondary controls, so at least one of them will not come last. iOS hacks around its lack of radio buttons by using a segmented control for proxy settings, and showing only the secondary controls for the currently selected proxy option immediately below it ... But even if that was a good idea, we can't do the same, because our toolkit doesn't have segmented controls either.

This is just the situation where radio buttons are absolutely necessary for coherent UI. Beyond that, though, radio items are often preferable to ItemSelectors simply because they are not list items, and therefore have a greater visual signal-to-noise ratio.