A more generalized version of #326119: Automatically Select Term for Required Vocabularies with One Term

Occasionally, there are select fields that are required, but only have one option to check. That option should be automatically listed as the default value. It would be a usability WTF to make users select that single option, especially if they forget to select it and failed form validation as a result.

Attached is the first version of a patch to do it. I don't have much exposure to the Fields API yet, so feedback (especially in terms of how to test this) would be helpful.

You can look at the discussion related to #326119: Automatically Select Term for Required Vocabularies with One Term to find some use cases for taxonomies, assuming it gets integrated with the Field API (#412518: Convert taxonomy_node_* related code to use field API + upgrade path), but since the Fields API is designed for general use in a lot of different contexts, I'm sure one can easily find many additional use cases for this.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bojhan’s picture

Could you use screenshots to describe some of the problem and the found solutions?

bjaspan’s picture

Status: Needs review » Needs work

I agree with the proposed behavior: A required select element with only one option should have that option selected automatically. However, this patch isn't right:

* It uses $field['cardinality'] to test if there is one option. $field['cardinality'] specifies how many times the field can appear on the form (e.g. with an "add more" button for "unlimited"), not how many potential values there are for a select list.
* As I read the code, a select list with only one valid value should only have one entry, in which case it will always be selected by default anyway with default browser behavior. If you have to specify the default element, it implies there is more than one, thus making this patch non-sensical. Perhaps there is a bug in which we are adding an empty select option to a required field? Such a bug might be in the options_options() function.

Please specify exactly how to reproduce the WTF behavior you are observing.

Mike Wacker’s picture

FileSize
4.32 KB

Here's an example screenshot. Currently the "Test" vocabulary is required has only one term, but for some curious reason I have to manually select that term.

A similar thing can happen with radios as well.

Mike Wacker’s picture

Title: Field is Required and has One Option - Automatically Select that Option » Button Option Field is Required, has One Option - Select that Option
Status: Needs work » Needs review
FileSize
1.5 KB
82.11 KB

The select option is already taken care of as bjaspan mentioned.

For the button option, this is still an issue. Attached is a screenshot of the problem as well as the patch.

I'm on the fence as to whether we need automated tests in SimpleTest for this, or if we should just manually test it.

bjaspan’s picture

I finally got some basic options.module unit tests written; see #557924: Options widget broken. I want the changes in this issue to have tests before it is RTBC. Unfortunately, the tests I've written so far reveal a bug with radio buttons, so the tests can't be committed yet. When they do, we'll circle back to this.

bjaspan’s picture

The patch in #4 contained a bug in setting the default value for checkboxes, revealed by the tests now included in this patch. However, the tests in this patch will fail until #605930: List field static caching bug on field_update_field() is committed.

bjaspan’s picture

Ooops, I put the wrong patch into the right filename. :-)

Status: Needs review » Needs work

The last submitted patch failed testing.

Mike Wacker’s picture

FileSize
1.76 KB
33.5 KB
1.79 KB
34.48 KB

I got some debugging output from the tests, and the 2 failures at lines 140 and 180 seem to be caused by the updates to the field not working.

You can see that the ['#fields'] part of the form seems to be correct but ['card_1/2'] is not. When the form is rendered, you still see the old options (1,2,3) instead of the single new option (99).

bjaspan’s picture

As I said in #6, the tests are failing due to a bug that is fixed in #605930: List field static caching bug on field_update_field(). The problem is that list.module is using a static cache for allowed values and is not clearing it when a field is changed intra-page load. Please go review that patch and mark it RTBC so this issue can then become RTBC. :-)

bjaspan’s picture

Status: Needs work » Needs review
Mike Wacker’s picture

Status: Needs review » Reviewed & tested by the community

Tests pass, so it looks like it's time to go RTBC

webchick’s picture

Status: Reviewed & tested by the community » Needs review

This change makes sense, usability-wise. However, it's quite an odd special-case code-wise.

Something I'd like to explore briefly is whether it makes sense to always auto-select a default option (defaulting to the first if none is specified), regardless if the radios are required or not. I learned over at #368771: Create Documentation about removing N/A option for not required radio buttons that the W3C recommends this as a best practice, since browser behaviour is undefined on a set of radio buttons with nothing selected by default.

See:
http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1
http://www.ietf.org/rfc/rfc1866.txt

Mike Wacker’s picture

It's an interesting idea, but I only favor the auto-select when there is one element.

I once attended a tech talk by Windows President Steven Sinofsky. He had two humorous slides. The first was a dialog box with a text label as well as yes, no, and cancel buttons. The second slide was the user perspective: same dialog box, but with no text anywhere except on the Yes button.

Regardless of what the W3C standard may recommend, if we do auto-select the first option, then the user may just go with that default even if it is a hilariously bad choice.

If there's a logical default, the programmer can specify it with a default value. If there is not, then the users should take the time to look at all the options and pick the best one, not the first one.

bjaspan’s picture

Wow, this is really unfortunate.

I'll start by saying that I'm not concerned by having special corner-case code for single-element lists. If the logical behavior requires a corner case, then we have a corner case. So what?

The "obviously correct" behavior for radio buttons is what is specified in the first paragraph of the HTML 4 spec for radio buttons: "Radio buttons are like checkboxes except that when several share the same control name, they are mutually exclusive: when one is switched "on", all others with the same name are switched "off"." So the radio-nature is defined by behavior when you click one of them, period. That means, clearly, that if NONE of the buttons start off checked and none are checked, they behave exactly like a set of checkboxes none of which are checked: they send no value.

However, the HTML 2 and HTML 4 spec disagree, and the HTML 4 spec says that user agents are inconsistent. Angie's point is: "Let's do the one thing that we know user agents will all handle correctly." Mike's point is: "Let's provide the most sensible UX." I want to agree with Mike, but if we do that, the result will be Drupal sites whose behavior depends on the user agent.

Does Drupal have a policy regarding which user agents it is willing to do stupid things in order to support? For example, we've put "security fixes" into Drupal that are really just workarounds for bugs in IE, because IE is important enough to warrant it, but we would not have done so for Cousin Joe's Visual Basic Web Browser Project.

Mike Wacker’s picture

Perhaps the best idea then is to commit the patch and consider this issue separately.

Obviously, when there's one radio button and it's a required element, the choice is obvious. The goal of this patch was to do the obvious.

In the not-so-obvious case, though, the default behavior (or non-behavior) will not change whether we commit the patch or not. Thus, committing the patch has no implications on this larger question at hand.

webchick’s picture

Status: Needs review » Fixed

Agreed with #16 (and #15; I'm not opposed to one-off code changes to fix bugs, but we would implement this fix differently if we were making this change to all radio elements). Opened #621366: Enforce comformance to W3C recommendations on radio buttons? for discussion. And as I was writing that up, it occurred to me that changing this behaviour would be an API change, so logged it against D8 as something we can consider in the future.

Committed to HEAD. Thanks!

Status: Fixed » Closed (fixed)
Issue tags: -Usability, -Needs tests

Automatically closed -- issue fixed for 2 weeks with no activity.