Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch After giving further thought to some of your suggestions I have revised my opinions. 1. A fieldset containing an input with a validation error MUST be expanded. It would be a major usability issue not to. The only question is whether to allow the fieldset to be collapsible or force it to not be collapsible. I might imagine a scenario where the user, once she has updated the input, would want to collapse the fieldset to look at other areas of the form but perhaps this scenario is unlikely or undesirable. 2. A fieldset containing an input that is required MUST be expanded by default. While it would be possible to style the collapsed fieldset to convey that it contains a required field, it would require the user to expand the fieldset before being able to input the required form data and it could prove too confusing to users since it would be an unusual UI method. Again, the only question is whether to allow a fieldset containing a required input to be collapsible. I find the scenario where a user would want to collapse a completed fieldset more likely in this instance so I would lean toward allowing it. 3. Since this change uses client-side scripting which may cause problems for or be negatively viewed by Drupal admins it may be desirable to provide a configuration setting to disable (or enable as the case may be) the functionality. Because the functionality is contained solely in the client-side code implementing this option should be as simple as checking for the preference and adding the "script" tag to the output or not and should not require adding any other checks elsewhere. Where would this configuration setting be placed though? Adding this option to the main settings screen seems like the logical place, for lack of a more suitable area. 4. The preview mode would, ideally, preserve the form state. If the user collapses a fieldset which is not collapsed by default then it should remain collapsed in the preview mode. While I haven't examined the preview method to see if it would support "form state" without modification I can't imagine that it does. I also imagine that adding this support could be more trouble than it is worth. How necessary is this feature? I am not going to concern myself with other collapsible form areas (e.g., tab groups) at this time. If this happens at some future time my implementation should be easy to extend to live within the new environment but it seems unnecessary to worry about it until it happens. tangent Previous comments: ------------------------------------------------------------------------ January 25, 2005 - 22:42 : tangent Attachment: http://drupal.org/files/issues/collapsible_formgroups.patch (2.8 KB) With all the talk of form reorganization and with the latest attempts at coding a solution, I thought I'd step up and contribute my solution. It is a quick development that I just threw together and it will probably need to be expanded to support more options, but it works and it has zero impact on existing code other than a small change to form_groups(). I've added an optional boolean parameter called "collapsed" so that modules can specify if the group should be initially collapsed or not. Known issues: 1. Styling the collapsed forms to look the same or even just good in every browser may prove troublesome. It looks fine in Mozilla/Firefox but the legend jumps around a bit in IE. I'm not terribly concerned about that at the moment though. 2. Required fields are not handled so a collapsed fieldset *could* contain a required field. This will need to be dealt with before this is a real solution, in my opinion. The difficulty lies in the fact that required fields are not labeled (in the markup) as such, other than by adding an extran span. Maybe we should think about adding a "required" attribute to required fields. I'm attaching the patch (against HEAD) now and will attach the javascript file shortly as well as a test page so you can see the functionality. As an aside, I'm setting this issue to patch status since that seems to be the process used around here. However, I think that generally an issue should ONLY be set to patch status if the attached file is worthy of being commited. Please correct me if I have misunderstood. ------------------------------------------------------------------------ January 25, 2005 - 22:44 : tangent Attachment: http://drupal.org/files/issues/drupal.js (1.68 KB) Here's the (new) drupal.js file. Note that don't necessarily think the functions included in it need to be loaded for every request. If more javascript is added, it should probably be broken up into separate pieces that can be sourced as need. ------------------------------------------------------------------------ January 25, 2005 - 22:46 : tangent Attachment: http://drupal.org/files/issues/fieldset_test.html (3.41 KB) Here's a stand-alone test page so you can see what the functionality would be like. Please report any issues with specific browsers by attaching your user-agent string or a description of your browser and the issue. Screenshots are welcome. ------------------------------------------------------------------------ January 26, 2005 - 03:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 03:27 : chx A cross browser solution to add event listeners can be found at http://www.scottandrew.com/weblog/articles/cbs-events That one works with Opera. ------------------------------------------------------------------------ January 26, 2005 - 03:45 : tangent Attachment: http://drupal.org/files/issues/fieldset_test2.html (3.84 KB) Here's an update of the test page. You should see the toggle image now and I've added extra event handling for all those substandard browsers ;-) I also corrected an issue where, if javascript is disabled, the group could be collapsed and not expandable. ------------------------------------------------------------------------ January 26, 2005 - 03:48 : tangent For what it's worth, if this functionality doesn't work in some browsers that's ok. As long as the code fails silently everything else will degrade nicely and they'll simply see all the forms. ------------------------------------------------------------------------ January 26, 2005 - 04:08 : tangent Attachment: http://drupal.org/files/issues/fieldset_test3.html (4.06 KB) This one might work better. I missed some stuff if the last one. I don't have Opera or Konqueror to test with though. I'm working a method to deal with required fields next. ------------------------------------------------------------------------ January 26, 2005 - 04:37 : Dries Looks good (though I haven't looked at the code). The node-edit/submit form would be an obvious candidate for this kind of stuff. Interesting! ------------------------------------------------------------------------ January 26, 2005 - 07:34 : tangent Should fieldset collapsing be optional? This implies that form_group() would need 2 new arguments: $collapsible and $collapsed. Someone has already voiced a desire for a configuration to enable/disable collapsible groups but I think that we should simply let the module decide. In my opinion it would be like offering a config preference for allowing expanding menus or not. ------------------------------------------------------------------------ January 26, 2005 - 08:35 : Bèr Kessels Attachment: http://drupal.org/files/issues/drupal_form_toolbox.png (19.23 KB) Great work! Some initial thoughts from me: We need logic to uncollapse forms that have the required flag set. (required forms should be visible by default) We need logic to uncollapse forms that have errors. The form group should, in this case get an extra class to show that, when collapsed, it contains an error, or a required field. We must think of a method to avoid colapses-in-collapses. I.E: you collapse form_group, which is great, but what if (i think bigger) we have three areas on a page, that can be collapsed: in that case, the form_groupos inside such an area should not be collapsible. We could decide to collapse the other forms, when opening one. This is somethimes called "cards", sometimes they are called "toolboxes' see attachement for an example. ------------------------------------------------------------------------ January 26, 2005 - 09:32 : mathias One usability issue surrounding collapsible elements is controlling how they would operate when present on the node editing form (which would be a great location for this functionality). For example what happens when someone clicks the preview button? I would want forms fields that contain data to stay expanded and not re-collapse. ------------------------------------------------------------------------ January 26, 2005 - 13:32 : tangent Attachment: http://drupal.org/files/issues/fieldset_test4.html (4.07 KB) Here's an updated test page that handles required fields the easy way. It simply borders the collapsed field with red. I think we should try this one out and discuss further before deciding on how best to deal with this issue. I am not immediately convinced that one solution is better than another. I've changed the addEvent function again to reduce it as far as possible. I am not convinced that the other version added support for any other browsers than this version so please correct me if I am mistaken. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204