This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
(ack nemo on #developers)
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.
zcorpan also suggests maybe making disabled="" a global attribute (or at least an attribute allowed on non-void <body> descendants).
disabled seems to be a global attribute in IE which grays text, disables form controls and contenteditable.
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...
Couldn't we simply add 'novalidate' attribute to form controls to make them barred from constraint validation?
(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.
(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.
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.
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.
mass-move component to LC1
This bug was cloned to create HTML WG bug 19035.
My guess is that this will end up WONTFIX, since it's easy enough to work around with a one-time utility function, and the use case is reasonably rare. But I'll look at this with the other forms-related feature requests.
(Of course if there's browser vendor interest in doing this, let me know.)
I'm punting this pending browser interest.
Closing due to lack of vendor interest. It's easy to write a function to do this.