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 9160 - input['type=checkbox'].checkValidity ought to work like the radio type, testing the whole checkbox group, not each checkbox individually
Summary: input['type=checkbox'].checkValidity ought to work like the radio type, testi...
Status: VERIFIED 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: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords: TrackerIssue
Depends on:
Blocks:
 
Reported: 2010-02-27 02:27 UTC by contributor
Modified: 2010-10-04 13:56 UTC (History)
6 users (show)

See Also:

Attachments

Description contributor 2010-02-27 02:27:17 UTC 
Section: http://www.whatwg.org/specs/web-apps/current-work/#checkbox-state

Comment:
Constraint validation ought to match a radio group; that is, if any checkbox
in the group is checked, the whole control is valid.  Not only would this
change make the API consistent for mutually-exclusive (radio) and
mutually-inexclusive (checkbox) widgets, but it has a broader set of
applications.  It is the rare case that someone would want to force a box to
be checked with the validation API, but enforcing that at least one box in a
group is checked is the exact sort of application that this API was designed
for.  If someone wants to force a box to be checked, he can always put it in
its own group.

Posted from: 75.141.192.2
Comment 1 Ian 'Hixie' Hickson 2010-03-30 01:17:40 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: In every other respect, checkboxes work independently of each other. I think it would be more confusing for checkboxes to work as a group in this case than to have them be different than radio buttons. Honestly I don't think any of the use cases with checkboxes really make sense, though the "you agree to these terms and conditions" use case is at least common, if not especially great for the user. What would the use case be for having one or more of a set of check boxes selected?
Comment 2 Brenton Simpson 2010-03-30 02:43:43 UTC 
The use case is the same as for a radio group, but with multiple selection.  Instead of "Choose one," it's "Choose all that apply."  Just as requiring a radio group requires that at least one be selected, requiring a checkbox group should require that at least one be selected.

What brought you in? (Choose all that apply.)
 - Food
 - Service
 - Atmosphere
 - Location

If this is required and a radio, one choice must be made.  If it is required and a checkbox group, I contend that at least one choice must be made.
Comment 3 Brenton Simpson 2010-03-30 02:57:44 UTC 
Title: What does input.@required mean for @type = checkbox?

Text:

This discussion revolves around the meaning of @required on a checkbox group in a survey.  By definition. a radio group must have only one choice selected if it is required.  A checkbox group functions identically to a radio group, but it can have multiple checked values.  I contend that a checkbox group must have at least one choice selected if it is required.

The spec currently dictates that @required directly relates to the checkbox it is on, without consideration for others in the group - right now, any required checkbox must be ticked.  Consider the following example.

Choose all that apply:
 - checkboxA
 - checkboxB
 - checkboxC

If any or each of these had the @required flag set under the proposed amendment, one or more must be checked.  Currently, any that is @required MUST be checked.

This amendment has no affect on checkbox widgets with unique names.  A checkbox with a unique name and the @required flag set will have the same meaning regardless of if the amendment is ratified.
Comment 4 Maciej Stachowiak 2010-03-30 03:20:29 UTC 
(In reply to comment #3)
> Title: What does input.@required mean for @type = checkbox?
> 

It's incorrect process to both reopen the bug *and* request escalation. Please pick one of the following:

1) Reopen bug for fresh consideration by the editor - you will get a full Editor's Response with rationale and a spec diff link if any spec changes are made.

2) Escalate to tracker for consideration by the full Working Group - a Change Proposal will be required.

In case of (1), the TrackerRequest keyword should be removed for now (you will still be entitled to request escalation once the editor replies again).

In case of (2), the bug should be moved back to VERIFIED - it will remain there and will not be closed pending a Working Group Decision.

If you do not pick one of these in a couple of days, we will assume option 2.
Comment 5 Brenton Simpson 2010-03-30 03:24:44 UTC 
Sorry for the confusion - this is my first W3C issue.

There's no option for VERIFIED.  First, I'll mark it WONTFIX again, then look for verified.  If I can't change it, Maciej, will you please?

Thank you.
Comment 6 Maciej Stachowiak 2010-03-30 03:39:01 UTC 
(In reply to comment #5)
> Sorry for the confusion - this is my first W3C issue.
> 
> There's no option for VERIFIED.  First, I'll mark it WONTFIX again, then look
> for verified.  If I can't change it, Maciej, will you please?
> 
> Thank you.
> 

Looks like you got it. Yes, it takes two steps to get to VERIFIED. Thanks for fixing the bug state!
Comment 7 Maciej Stachowiak 2010-05-12 03:40:38 UTC 
http://www.w3.org/html/wg/tracker/issues/111