This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10833 - The element should only suffer from being missing if all of the checkbox choices are unselected - like radio buttons
Summary: The element should only suffer from being missing if all of the checkbox choi...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-29 15:00 UTC by contributor
Modified: 2010-10-12 16:09 UTC (History)
8 users (show)

See Also:


Attachments

Description contributor 2010-09-29 15:00:23 UTC
Section: http://www.whatwg.org/specs/web-apps/current-work/#checkbox-state

Comment:
The element should only suffer from being missing if all of the checkbox
choices are unselected - like radio buttons

Posted from: 62.232.34.19
Comment 1 Ian 'Hixie' Hickson 2010-10-07 21:47:01 UTC
What do browser vendors think? Worth changing?
Comment 2 Jonas Sicking (Not reading bugmail) 2010-10-07 22:00:05 UTC
I don't have a strong opinion. The only argument I can think of is that people sometimes use multiple checkboxes in place of <select multiple> since the UI for the latter is pretty terrible. And we do allow @required on the latter.
Comment 3 Maciej Stachowiak 2010-10-07 22:05:20 UTC
I don't see a problem with implementing either behavior.

However, checkboxes, unlike radio buttons, do not have any behavior currently that groups via name. This change would be the first to introduce it. Certainly it would not make sense to apply to unnamed checkboxes or to all checkboxes in a form. For example, often a EULA form will have separate "I have read this" and "I agree" checkboxes in the same form which are both independently required to be checked. So this would be the first behavior to treat checkboxes as grouped like radio buttons, which might be confusing.

"Required" also seems like an odd concept for a single checkbox. There are cases (like the aforementioned EULA) where checking a particular checkbox is mandatory to submit the form. But in other cases, on and off are both equally valid states, and can be a willful choice by the user. So that seems different from other uses of required, where they form control fails validation only if, in some sense, "nothing has been chosen".
Comment 4 Jonas Sicking (Not reading bugmail) 2010-10-07 22:13:29 UTC
To be clear, I definitely think that

<form>
  <input type=checkbox name=a required>
  <input type=checkbox name=b required> <!-- Note, different name -->
</form>

Should be allowed and should require that *both* checkboxes are checked. It was unclear to me if you agreed with that or not Maciej?

What I interpreted the scope of this bug to was if the following markup required only one of the boxes to be checked, or if both had to be checked:

<form>
  <input type=checkbox name=a required>
  <input type=checkbox name=a required> <!-- Note, same name -->
</form>

There is also the complication of what to do with markup like:

<form>
  <input type=checkbox name=a required>
  <input type=checkbox name=a> <!-- Note, required missing -->
</form>
This complication is the main reason I'm hesitant to treat the boxes as a group.
Comment 5 Anne 2010-10-08 09:17:59 UTC
In Opera right now they work per checkbox. Whether the checkbox is also in a group does not seem to be taken into account. If we do take grouping into account I think both examples Jonas gave at the end of comment 4 should be treated the same way.

Having said that, I think the use case here is the single checkbox, which does not require grouping to be taken into account. So maybe we should keep it simple.
Comment 6 Doug Wright 2010-10-08 12:32:53 UTC
Hi

I was indeed thinking of the case where multiple checkboxes are used instead of <select multiple> - I've never seen a normal user successfully work out the ctrl+click behaviour needed to actually select multiple options without explicitly being told.

Often forms have questions that ask "please tick all that apply". As the spec stands, there is no way to make this be a compulsory question using @required.
Comment 7 Ian 'Hixie' Hickson 2010-10-12 09:57:46 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The argument that this would be introducing checkbox grouping for the first time, and that that is a bit weird, is stronger IMHO than the argument that the feature is useful.

There are ways to do "select all that apply, and select at least one" -- use <select multiple required>. This has the advantage of being much more usable UI-wise.
Comment 8 Jonas Sicking (Not reading bugmail) 2010-10-12 16:09:35 UTC
> There are ways to do "select all that apply, and select at least one" -- use
> <select multiple required>. This has the advantage of being much more usable
> UI-wise.

Actually, that is generally not true. The fact that you have to control-click to select several items makes it hard enough that I think many sites don't consider it an option.

I am however fine with waiting with this and seeing what author feedback we get. The situation here is different from <select required> since we'd be loosening the restricted behavior, not tightening it.