Spill-over from #569542: Button Option Field is Required, has One Option - Select that Option and #368771-24: Create Documentation about removing N/A option for not required radio buttons:

From http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1 (I tried to find an XHTML version of this section, and failed):

If no radio button in a set sharing the same control name is initially "on", user agent behavior for choosing which control is initially "on" is undefined. [snip] Since user agent behavior differs, authors should ensure that in each set of radio buttons that one is initially "on".

See also http://www.ietf.org/rfc/rfc1866.txt

The recommendation is basically saying that there should never be a situation where radio buttons appear that do not have one of the options pre-selected. Mainly, I guess, because you can never "un" select one of the options in a list of radios once you click into it. If you want a control where users have to explicitly choose something, you should use a select box instead which can have a 'neutral' option.

What CCK (and presumably Field UI) does is, for required fields, always select the first one in the list. For non-required fields, it automatically creates an "N/A" option to give people the ability to not fill out the field.

Basically, I guess the question is... should Form API enforce this recommendation, and disallow radio button controls without a #default_value (probably defaulting to the first option if none is selected)? People who still wanted "N/A" as one of the choices could still add it in there as one of the $options.

Anyone here web a standards geek?

Comments

ekes’s picture

roderik’s picture

Clients regularly want options in a form to:
- be required
- be displayed as radio buttons - because, "you know, they look better/more intuitive than a select box"
- not have any option preselected - because that is better to prevent wrongly entered data. (Depending on client profession: "it's better for conversion".)

They don't know why that isn't possible. Heck, I still never figured it wasn't possible, and am being bitten by #1 now.

So...

Here's a wild idea for the radiobuttons widget, that will
- always conform to W3C specs
- not enable ignorant site builders like myself to set up an 'invalid' state
- educate these people about why this is the case.

    Idea:

  1. If checkboxes have #required=true but no #default_value, display another checkbox above the choices, just like is being done for non-required fields, but labeled "Select a value". Select this option. Give error when it is still selected on form validation.
  2. In the Field settings edit screen, provide a short help text at the "required" checkbox:
      A required field with radio buttons must have a default value.
  3. in the "default value" fieldset (where a radio button labeled "N/A" is always displayed), provide help text:
      Sets of radio buttons in a browser must always have one option selected, as per W3C specifications [link]. Fields which are not 'required', will therefore have an extra radio button labeled "N/A" above the regular options, which can be used to 'unselect' the field value. Required fields will also have an extra radio button on the screen (labeled "Select a value"), if a default value is not chosen here.

@webchick: with the above, the answer to your questions is "yes, let's have Form API enforce this recommendation." But not by disallowing enforcing default values.

Let them hide it using CSS. Make it easy to do so, by providing a CSS selector if that isn't there yet / documentation.

That may seem like an ugly hack, but at least it's predictable (there is no 'unspecified state => unpredictable browser behavior'). And no back-end troubles; no way to hit bugs like #811542 by setting up a radiobuttons widget with an invalid state -- also not when you set up a 'required field without default value' with a select box first, and then switch the widget to radio buttons.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)

Currently going through the end of the queue to see what could still be relevant for D10.

Wonder if this is still needed for D10?

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

Almost 2 years later and no response was given about this being needed or not. So, closing this issue,

If this needs to be done, wither re-open the issue and add a comment or open a new issue and reference this one.