19035 – We should handle the case of a bunch of required controls all being hidden at once — the author shouldn't have to also go in an remove the 'required' attribute on each one. Maybe make hidden="" bar things from constraint validation?

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 19035 - We should handle the case of a bunch of required controls all being hidden at once — the author shouldn't have to also go in an remove the 'required' attribute on each one. Maybe make hidden="" bar things from constraint validation?

Summary: We should handle the case of a bunch of required controls all being hidden at...

Status:	RESOLVED LATER

Alias:	None

Product:	HTML WG
Classification:	Unclassified
Component:	HTML5 spec (show other bugs)
Version:	unspecified
Hardware:	Other other

Importance:	P3 normal
Target Milestone:	---
Assignee:	This bug has no owner yet - up for the taking
QA Contact:	HTML WG Bugzilla archive list

URL:	http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2012-09-25 21:57 UTC by contributor
Modified:	2012-09-25 22:26 UTC (History)
CC List:	7 users (show)

See Also:

Attachments

Description contributor 2012-09-25 21:57:27 UTC

This was was cloned from bug 11794 as part of operation LATER convergence.
Originally filed: 2011-01-18 20:52:00 +0000

================================================================================
 #0   contributor@whatwg.org                          2011-01-18 20:52:52 +0000 
--------------------------------------------------------------------------------
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#barred-from-constraint-validation

Comment:
We should handle the case of a bunch of required controls all being hidden at
once — the author shouldn't have to also go in an remove the 'required'
attribute on each one. Maybe make hidden="" bar things from constraint
validation?

Posted from: 76.102.14.57 by ian@hixie.ch
================================================================================
 #1   Ian 'Hixie' Hickson                             2011-01-18 20:53:22 +0000 
--------------------------------------------------------------------------------
(ack nemo on #developers)
================================================================================
 #2   Ian 'Hixie' Hickson                             2011-01-18 21:09:05 +0000 
--------------------------------------------------------------------------------
zcorpan points out this was considered before (though without a use case, it seems):
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027624.html

<fieldset disabled> is the main way we've said to do this in the past, but the case that raised this this time had markup involving nested lists, where a fieldset would be a bit awkward.
================================================================================
 #3   Ian 'Hixie' Hickson                             2011-01-18 21:10:38 +0000 
--------------------------------------------------------------------------------
zcorpan also suggests maybe making disabled="" a global attribute (or at least an attribute allowed on non-void <body> descendants).
================================================================================
 #4   Simon Pieters                                   2011-01-18 21:22:09 +0000 
--------------------------------------------------------------------------------
disabled seems to be a global attribute in IE which grays text, disables form controls and contenteditable.
================================================================================
 #5   Boris Zbarsky                                   2011-01-18 21:42:16 +0000 
--------------------------------------------------------------------------------
The issue with overloading @hidden this way is that anytime it's used the browser would have to check for form controls that are descendants of the node whose @hidden is being changed.  This means either making @hidden changes slower in all cases, or optimizing for the case of no form descendants and maintaining state on ancestors of form controls (making form control insertion and/or removal slower).

For fieldset's @disabled what Gecko does is that fieldsets observe changes to the DOM under them, and when form controls are added add them to a list stored in the fieldset.  This makes @disabled changes fast, and only affects insertion/removal of nodes under fieldsets (and in a pretty minor way).  It costs a bit more memory per fieldset node, but those are rare.  This approach wouldn't work for arbitrary @hidden, because the extra memory cost per node for _all_ elements doesn't seem desirable...
================================================================================
 #6   Mounir Lamouri                                  2011-01-19 21:59:11 +0000 
--------------------------------------------------------------------------------
Couldn't we simply add 'novalidate' attribute to form controls to make them barred from constraint validation?
================================================================================
 #7   Simon Pieters                                   2011-01-20 10:10:12 +0000 
--------------------------------------------------------------------------------
(In reply to comment #6)
> Couldn't we simply add 'novalidate' attribute to form controls to make them
> barred from constraint validation?

That wouldn't address the problem this bug describes since it's equally annoying to add novalidate to all affected controls as it is to add disabled or remove required on them.
================================================================================
 #8   Mounir Lamouri                                  2011-01-20 10:42:42 +0000 
--------------------------------------------------------------------------------
(In reply to comment #7)
> (In reply to comment #6)
> > Couldn't we simply add 'novalidate' attribute to form controls to make them
> > barred from constraint validation?
> 
> That wouldn't address the problem this bug describes since it's equally
> annoying to add novalidate to all affected controls as it is to add disabled or
> remove required on them.

Disabled would prevent the form control from being submitted. That wouldn't be the same as barring it from constraint validation.

And removing required is one use case. Having an attribute to bar the element from constraint validation would work easily in all situations.

Maybe we could also make novalidate set on a fieldset barring all fieldset descendants from constraint validation.
================================================================================
 #9   Boris Zbarsky                                   2011-01-20 14:49:13 +0000 
--------------------------------------------------------------------------------
Right, that's the other questions.  When would one hide a bunch of unrelated controls?  And shouldn't related controls be in a fieldset?

I'd be happy with making novalidate on fieldsets imply it for all controls in the fieldset.
================================================================================
 #10  Ian 'Hixie' Hickson                             2011-02-16 08:15:26 +0000 
--------------------------------------------------------------------------------
The use case in question is something like a list where each list item can be toggled between representing either nothing or a set of further fields nested within it. You want each nested field to be disabled when the parent list item is in the "off" state, and enabled otherwise, and you don't want to have to crawl the tree manually each time.

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: Partially Accepted
Change Description: none yet
Rationale: I'm going to postpone this for now, since there are temporary (if awkward) workarounds in the use of <fieldset> or in the use of utility functions that crawl the tree marking elements as disabled, and since the use case isn't a huge use case, and since the proposed solutions have real problems and I don't have a better proposal at the moment.
================================================================================