Re: required radio buttons and checkboxes

Ben Boyle wrote:
> On Tue, Apr 22, 2008 at 9:59 PM, Philip Taylor <pjt47@cam.ac.uk> wrote:
>>> For checkboxes, the required attribute shall only be satisfied when one
>>> or more of the checkboxes with that name in that form are checked.
>>>
>>> For radio buttons, the required attribute shall only be satisfied when
>>> exactly one of the radio buttons in that radio group is checked.
> 
> This explains the 'checked' status needed to satisfy a 'required'
> input. I understand the behaviour. What isn't explained is whether
> that 'required' status is determined by one or more required
> attributes within the group.

It explains when a 'required' *attribute* is satisfied. The "Validation 
APIs" section specifies how a form control element is invalid if it has 
an unsatisfied 'required' attribute, and "Form submission" specifies how 
a form wouldn't be submitted if it has any invalid form control elements.

It might be clearer (or not) backwards: You start by wondering whether 
the form is valid. To do that, you look through each element in the 
form, and see if that element is valid. To see if an element is valid, 
you see if it has an unsatisfied 'required' attribute. To see that, you 
see if it has a 'required' attribute, and then see if it is satisfied 
(using the quoted definition at the top of this email). If you've found 
at least one invalid element, then the form is invalid and you notify 
the user somehow.

>>> When a radio group has no checked radio button and more than one of the
>>> radio buttons is marked as required, the UA, when alerting the user,
>>> should only tell the user that the radio group as a whole is missing a
>>> value, not complain about each radio button in turn, even though all of
>>> the radio buttons marked with the required attribute would have the
>>> valueMissing flag set.
> 
> 'more than one of the radio buttons is marked as required' suggested
> @required must be applied to at least two input elements with the same
> name (and type=radio of course), i.e. in the group.

This is only talking about the "notify the user somehow" phase, once 
you've already determined that the form is invalid - it doesn't affect 
the form's validity.

In a form like <input name=first_name required><input name=last_name 
required>, the UA should highlight both required input fields and give 
two "you need to fill in this field" messages if you try to submit the 
form without filling them in.

In a form like <input type=radio name=whatever required><input 
type=radio name=whatever required>, with more than one required input 
control, the UA should only give you a single "you need to select one 
option here" message for the entire radio group (unlike the previous 
example, where it complained about each invalid input), which is what 
the spec paragraph above is talking about.

> It may be possible in a group of checkboxes to 'require' individual
> boxes be selected? Sometimes this is useful business logic (e.g. you
> have a set of options, and a previous action has caused some to be
> checked - and required - from that point).

It seems clearer to use 'disabled' rather than 'required' when people 
aren't meant to uncheck a checkbox. I think that kind of logic would 
have to be handled by scripts - you could do something like:

  <p>Force the next option on? <input type="checkbox" onchange="
    var opt = document.getElementById('opt');
    if (this.checked) {
      opt._waschecked = opt.checked;
      opt.checked = true;
    } else {
      opt.checked = opt._waschecked;
    }
    opt.disabled = this.checked;
   ">
  <p>This is the next option: <input type="checkbox" id="opt">

(but with more abstraction instead of onchange attributes), depending on 
exactly what behaviour you want.

> Must admit I'm finding it harder to comprehend than xforms
> select1/select controls and required expressions (and they're a good
> bit richer in functionality). Will get there though.

WF2 doesn't seem an easy-to-read spec to me - I think that's partly 
because it's missing a load of details that were meant to be defined in 
HTML4/DOM2/etc, and it would be much more coherent with everything 
merged into a single document. Then it might become as easy to read as 
the HTML5 spec, in which case we'll really need people to write 
tutorials and examples and guides for authors :-)

> cheers
> Ben

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Wednesday, 23 April 2008 14:08:00 UTC