- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Sep 2012 21:57:27 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19035 Summary: 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? Product: HTML WG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#bar red-from-constraint-validation OS/Version: other Status: NEW Severity: normal Priority: P3 Component: HTML5 spec AssignedTo: dave.null@w3.org ReportedBy: contributor@whatwg.org QAContact: public-html-bugzilla@w3.org CC: ian@hixie.ch, bzbarsky@mit.edu, mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org, ayg@aryeh.name, mounir.lamouri@gmail.com 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. ================================================================================ -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 25 September 2012 21:58:21 UTC