[drupal-devel] [feature] Form groups should be collapsible
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 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. tangent -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 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. 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 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. 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
On Tuesday 25 January 2005 22:46, tangent wrote:
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.
Good evening! This works fine for me under Firefox 1.0 on Linux, but not under Konqueror 3.3.0. One suggestion: I think there should be some feedback visually on the form group heading, to indicate that its state can be toggled. This is especially true when it's collapsed, to indicate that there's something "inside" it. Right now the only thing I see is that the form group heading is a link. Other than that, it's a neat piece of functionality! I do hope that if this becomes part of core, that it will be an admin and/or user preference setting. I like it personally, but I could very well imagine that it might not be to everyone's taste, especially the technophobic. :-) Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
On Tue, 25 Jan 2005 23:28:08 -0500, Scott Courtney <scott@4th.com> wrote:
On Tuesday 25 January 2005 22:46, tangent wrote:
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.
Good evening!
This works fine for me under Firefox 1.0 on Linux, but not under Konqueror 3.3.0.
Do you have an error line or anything?
One suggestion: I think there should be some feedback visually on the form group heading, to indicate that its state can be toggled. This is especially true when it's collapsed, to indicate that there's something "inside" it. Right now the only thing I see is that the form group heading is a link.
Actually, there is a toggle image which isn't showing on the test page since I didn't include a base tag. I'll attach a new test page so you can see that. I don't know how much this will help but these are "theme" issues so don't really bear on the functionality in any case. Cheers, Chris
On Tuesday 25 January 2005 22:46, tangent wrote:
Please report any issues with specific browsers by attaching your user-agent string or a description of your browser and the issue.
Doh! I mentioned this failed under Konqueror 3.3.0, but I forgot to say what was wrong. Basically, clicking on the form group headers does nothing, even with JavaScript fully enabled. No errors or anything, just ignored clicks. Sorry for not having reported more specifically in my previous post. Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Junyor Status: patch FYI, window.addEventListener is not supported in Opera. Junyor Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: chx Status: patch 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. chx Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 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. 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 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. 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 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. 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
On Wednesday 26 January 2005 04:08, tangent wrote:
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.
This new version works flawlessly for me in Firefox 1.0 on Linux, but still is non-functional in Konqueror 3.3.0. It does, however, fail gracefully (with all sections expanded) in Konqueror. -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
On Wed, 26 Jan 2005 04:54:31 -0500, Scott Courtney <scott@4th.com> wrote:
This new version works flawlessly for me in Firefox 1.0 on Linux, but still is non-functional in Konqueror 3.3.0. It does, however, fail gracefully (with all sections expanded) in Konqueror.
If someone who uses Konqueror and knows something about it's DOM compatibility can tell me what the problem is I'll be happy to fix it.
On Wednesday 26 January 2005 04:58, Chris Cook wrote:
On Wed, 26 Jan 2005 04:54:31 -0500, Scott Courtney <scott@4th.com> wrote:
This new version works flawlessly for me in Firefox 1.0 on Linux, but still is non-functional in Konqueror 3.3.0. It does, however, fail gracefully (with all sections expanded) in Konqueror.
If someone who uses Konqueror and knows something about it's DOM compatibility can tell me what the problem is I'll be happy to fix it.
Just as an FYI... You may want to be aware of this bug that I've reported. I don't know if it impacts your work or not, but I thought it best to pass along the information. It's either a Konqueror bug -- though I use Konqueror for eight hours a day and have never seen it on a single non-Drupal web site -- or it's a really obscure CSS bug in drupal.css. Anyway, here's the issue URL, for your reference: http://drupal.org/node/16729 . If this doesn't affect your work, then I apologize for the bandwidth. Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
On Wed, 26 Jan 2005 04:54:31 -0500, Scott Courtney <scott@4th.com> wrote:
On Wednesday 26 January 2005 04:08, tangent wrote:
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.
This new version works flawlessly for me in Firefox 1.0 on Linux, but still is non-functional in Konqueror 3.3.0. It does, however, fail gracefully (with all sections expanded) in Konqueror.
The same goes for Opera (i.e. it fails gracefully). -- Tim Altman
Scott Courtney wrote:
This new version works flawlessly for me in Firefox 1.0 on Linux, but still is non-functional in Konqueror 3.3.0. It does, however, fail gracefully (with all sections expanded) in Konqueror.
I tried with Konqueror 3.3.2 and it works for me. -- Dries Buytaert :: http://www.buytaert.net/
Scott Courtney schreef:
On Wednesday 26 January 2005 04:08, tangent wrote:
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.
This new version works flawlessly for me in Firefox 1.0 on Linux, but still is non-functional in Konqueror 3.3.0. It does, however, fail gracefully (with all sections expanded) in Konqueror.
Fails gracefully in IE 5.2, works like a charm on Firefox 1.0 and Safari 1.2.4 all on the Mac. Stefan
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch 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! Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 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. 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! -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Bèr Kessels Status: patch 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. Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: mathias Status: patch 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. mathias 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 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. 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
On Wed, 26 Jan 2005 19:32:51 +0100, tangent <drupal-devel@drupal.org> wrote:
Attachment: http://drupal.org/files/issues/fieldset_test4.html
[...]
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.
With this test page, the fieldset is collapsed by default and cannot be expanded at all in Opera. The second and third test pages both had the fieldset expanded by default. Couldn't you download a couple more browsers and use them for your testing? I guess this is a good example of why we don't use JavaScript for ofter in core. :( -- Tim Altman
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.
Very strange. This addEvent looks like the crossbrowser solution by Scott Andrew I've pointed to before which I can testify that one works perfectly with Opera, FF, IE, Konqueror -- contact me for test URL. Regards Karoly Negyesi
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
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: moshe weitzman Status: patch Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. moshe weitzman 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Steven Status: patch I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as: html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. Steven Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as: html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Junyor Status: patch Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 Junyor Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as: html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Steven Status: patch "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? Steven Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Bèr Kessels Status: patch JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Anonymous Status: patch Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. Anonymous Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 03: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 26, 2005 - 03: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 26, 2005 - 03: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 - 08:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 08: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 - 08: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 - 08: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 - 09: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 - 09: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 - 12: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 - 13: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 - 14: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 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 08:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 15:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 15:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 14:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 07:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 19:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 10:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 14:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 14:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 14:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
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 Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal -Version: 4.5.2 +Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 22:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 22:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 7, 2005 - 22:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 22:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 7, 2005 - 22:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 7, 2005 - 23:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 22:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 7, 2005 - 22:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 7, 2005 - 23:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 7, 2005 - 23:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 22:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 7, 2005 - 22:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 7, 2005 - 23:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 7, 2005 - 23:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 04:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Bèr Kessels Status: patch Can you not use .fieldset-collapsed * { display: none; } , Tangent? Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 22:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 7, 2005 - 22:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 7, 2005 - 23:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 7, 2005 - 23:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 04:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 06:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? -- View: http://drupal.org/node/16204 Edit: http://drupal.org/project/comments/add/16204
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: moshe weitzman Status: patch what is the status here? tangent? UnConed? is this ready for review? moshe weitzman 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. ------------------------------------------------------------------------ January 27, 2005 - 03:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 07:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 10:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 10:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 09:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 02:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 14:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 05:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 09:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 09:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 09:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 16:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 22:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 23:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 22:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 22:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 22:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 7, 2005 - 22:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 7, 2005 - 23:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 7, 2005 - 23:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 04:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 06:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 06:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: magico Status: patch any update to this? magico Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 03: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 26, 2005 - 03: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 26, 2005 - 03: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 - 08:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 08: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 - 08: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 - 08: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 - 09: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 - 09: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 - 12: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 - 13: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 - 14: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 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 08:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 15:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 15:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 14:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 07:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 19:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 10:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 14:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 14:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 14:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 21:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 03:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 04:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 03:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 03:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 03:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 04:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 04:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 09:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 10:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 11:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 11:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 21:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review?
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [1] library, especially when it's combined with a few extensions [2]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [3] is a good example of an application using javascript to add some nice features for users (uses the above library). [1] http://prototype.conio.net/ [2] http://taskthis.darthapo.com/javascripts/prototype-ex.js [3] http://taskthis.darthapo.com Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 03: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 26, 2005 - 03: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 26, 2005 - 03: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 - 08:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 08: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 - 08: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 - 08: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 - 09: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 - 09: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 - 12: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 - 13: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 - 14: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 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 08:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 15:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 15:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 14:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 07:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 19:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 10:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 14:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 14:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 14:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [4] for more information. [4] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 21:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 03:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 04:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 03:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 03:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 03:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 04:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 04:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 09:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 10:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 11:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 11:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 21:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 16:46 : magico any update to this?
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: drumm Status: patch If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. drumm Previous comments: ------------------------------------------------------------------------ January 25, 2005 - 21: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 - 21: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 - 21: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 - 02:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 02: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 - 02: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 - 02: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 - 03: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 - 03: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 - 06: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 - 07: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 - 08: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 - 12: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. ------------------------------------------------------------------------ January 27, 2005 - 02:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 06:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 09:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 09:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 08:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 01:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 13:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 04:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 08:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 08:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 08:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 15:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 6, 2005 - 21:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 6, 2005 - 22:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 7, 2005 - 21:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 7, 2005 - 21:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 7, 2005 - 21:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 7, 2005 - 21:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 7, 2005 - 21:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 7, 2005 - 21:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 7, 2005 - 22:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 7, 2005 - 22:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 03:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 05:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 05:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 15:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 10:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 11:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Bèr Kessels Status: patch Drumms remark is also what we agreed upon on the meetings in Antwerp. Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Steven Status: patch I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. Steven Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) If a fieldset has a class of "collapsed" AND the fieldset contains no EMPTY form elements that have a class of "required" AND the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Steven Status: patch Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. Steven Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp;
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 03: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 26, 2005 - 03: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 26, 2005 - 03: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 - 08:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 08: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 - 08: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 - 08: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 - 09: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 - 09: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 - 12: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 - 13: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 - 14: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 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 08:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 15:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 15:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 14:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 07:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 19:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 10:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 14:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 14:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 14:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 21:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 03:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 04:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 03:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 03:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 03:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 04:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 04:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 09:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 10:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 11:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 11:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 21:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 16:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 17:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 19:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 20:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 04:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 07:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 04:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Junyor Status: patch Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? Junyor Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 08:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 05:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 09:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 10:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible).
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Junyor Status: patch Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? Junyor Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 08:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 05:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 09:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 10:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 12:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do?
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: factoryjoe Status: patch Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. factoryjoe Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 03: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 26, 2005 - 03: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 26, 2005 - 03: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 - 08:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 08: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 - 08: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 - 08: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 - 09: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 - 09: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 - 12: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 - 13: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 - 14: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 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 08:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 15:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 15:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 14:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 07:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 19:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 10:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 14:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 14:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 14:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 21:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 03:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 04:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 03:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 03:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 03:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 04:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 04:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 09:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 10:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 11:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 11:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 21:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 16:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 17:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 19:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 20:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 04:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 07:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 04:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 08:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 09:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 11:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 11:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements?
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 03: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 26, 2005 - 03: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 26, 2005 - 03: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 - 08:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 08: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 - 08: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 - 08: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 - 09: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 - 09: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 - 12: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 - 13: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 - 14: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 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 08:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 15:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 15:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 14:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 07:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 19:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 10:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 14:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 14:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 14:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 21:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 03:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 04:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 03:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 03:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 03:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 04:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 04:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 09:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 10:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 11:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 11:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 21:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 16:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 17:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 19:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 20:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 04:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 07:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 04:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 08:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 09:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 11:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 11:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 20:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: stefan nagtegaal Status: patch "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) stefan nagtegaal Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 03: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 26, 2005 - 03: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 26, 2005 - 03: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 - 08:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 08: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 - 08: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 - 08: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 - 09: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 - 09: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 - 12: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 - 13: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 - 14: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 - 18: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. ------------------------------------------------------------------------ January 27, 2005 - 08:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 12:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 15:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 15:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 14:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 07:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 19:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 10:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 14:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 14:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 14:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 21:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 03:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 04:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 03:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 03:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 03:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 03:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 04:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 04:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 09:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 10:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 11:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 11:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 21:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 16:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 17:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 19:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 20:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 04:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 07:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 04:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 08:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 09:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 11:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 11:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 20:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 08:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 08:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-)
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 08:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 05:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 09:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 10:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 12:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 12:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 21:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 09:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 09:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 10:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 13:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 20:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action.
On Friday 03 June 2005 14:13, Dries wrote:
June 3, 2005 - 20:09 : Dries
Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB)
Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action.
Where would one obtain the current patch set, or, alternatively, is there a test site up and running somewhere? Given the problems we saw with fieldsets in Konqueror, I'd like to help out by testing this new feature in that browser. I can either install it on my development site (running Drupal 4.6.1 now) or go to someone else's site. It looks like a great feature -- kudos to the developers. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 08:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 05:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 09:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 10:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 12:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 12:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 21:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 09:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 09:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 10:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 13:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 18:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 19:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 19:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ...
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 20:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 20:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 23:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end?
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.) Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 20:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 20:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 23:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 09:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.)
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch Attachment: http://drupal.org/files/issues/collapsible.png (31.65 KB) I made a PNG with an overview of the "bigger picture". The overview identifies related work/patches and shows that collapsible page elements are somewhat of an enabler. Please take a look! Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 20:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 20:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 23:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 09:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) ------------------------------------------------------------------------ June 5, 2005 - 11:21 : Dries For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.)
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/collapse_1.patch (12.72 KB) Latest patch includes collapsing elements on the node creation groups (plus a new group around the input formats). I considered creating an "Advanced Editting" group around the top three groups (author, options & comments). I've not implemented that yet, as I'm very much liking the Node creation redesign [1] discussion. Screenshots: * admin/settings [2] * node/add/story [3] [1] http://drupal.org/node/15506 [2] http://www.flickr.com/photos/thox/18155964 [3] http://www.flickr.com/photos/thox/18155963 Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [4] for more information. [4] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [5] library, especially when it's combined with a few extensions [6]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [7] is a good example of an application using javascript to add some nice features for users (uses the above library). [5] http://prototype.conio.net/ [6] http://taskthis.darthapo.com/javascripts/prototype-ex.js [7] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 08:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 05:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 09:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 10:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 12:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 12:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 21:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 09:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 09:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 10:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 13:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 18:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 19:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 19:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 22:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 08:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) ------------------------------------------------------------------------ June 5, 2005 - 10:21 : Dries For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.) ------------------------------------------------------------------------ June 5, 2005 - 17:51 : Dries Attachment: http://drupal.org/files/issues/collapsible.png (31.65 KB) I made a PNG with an overview of the "bigger picture". The overview identifies related work/patches and shows that collapsible page elements are somewhat of an enabler. Please take a look!
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/collapse_2.patch (13.48 KB) Added patch of comment.module and changed the node "Options" group to be called "Publishing Options". Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 08:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 05:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 09:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 10:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 12:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 12:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 21:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 09:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 09:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 10:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 13:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 18:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 19:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 19:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 22:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 08:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) ------------------------------------------------------------------------ June 5, 2005 - 10:21 : Dries For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.) ------------------------------------------------------------------------ June 5, 2005 - 17:51 : Dries Attachment: http://drupal.org/files/issues/collapsible.png (31.65 KB) I made a PNG with an overview of the "bigger picture". The overview identifies related work/patches and shows that collapsible page elements are somewhat of an enabler. Please take a look! ------------------------------------------------------------------------ June 8, 2005 - 11:05 : Thox Attachment: http://drupal.org/files/issues/collapse_1.patch (12.72 KB) Latest patch includes collapsing elements on the node creation groups (plus a new group around the input formats). I considered creating an "Advanced Editting" group around the top three groups (author, options & comments). I've not implemented that yet, as I'm very much liking the Node creation redesign [5] discussion. Screenshots: * admin/settings [6] * node/add/story [7] [5] http://drupal.org/node/15506 [6] http://www.flickr.com/photos/thox/18155964 [7] http://www.flickr.com/photos/thox/18155963
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: stefan nagtegaal Status: patch Damn, this is really nice! Works flawelessly on my localhost... Nothing more to say.. Very, very nice and good patch. stefan nagtegaal Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 20:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 20:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 23:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 09:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) ------------------------------------------------------------------------ June 5, 2005 - 11:21 : Dries For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.) ------------------------------------------------------------------------ June 5, 2005 - 18:51 : Dries Attachment: http://drupal.org/files/issues/collapsible.png (31.65 KB) I made a PNG with an overview of the "bigger picture". The overview identifies related work/patches and shows that collapsible page elements are somewhat of an enabler. Please take a look! ------------------------------------------------------------------------ June 8, 2005 - 12:05 : Thox Attachment: http://drupal.org/files/issues/collapse_1.patch (12.72 KB) Latest patch includes collapsing elements on the node creation groups (plus a new group around the input formats). I considered creating an "Advanced Editting" group around the top three groups (author, options & comments). I've not implemented that yet, as I'm very much liking the Node creation redesign [5] discussion. Screenshots: * admin/settings [6] * node/add/story [7] [5] http://drupal.org/node/15506 [6] http://www.flickr.com/photos/thox/18155964 [7] http://www.flickr.com/photos/thox/18155963 ------------------------------------------------------------------------ June 8, 2005 - 13:19 : Thox Attachment: http://drupal.org/files/issues/collapse_2.patch (13.48 KB) Added patch of comment.module and changed the node "Options" group to be called "Publishing Options".
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Steven Status: patch Looking great... some notes: - I don't see how the "fieldsets with errors should open" works. I can see some code for checking that, but it is only invoked in a.onclick. There is also an unused variable collapse_action. Can you check this? It is an important feature IMO. - The administration options at the top are a bit weird... at a glance, it looks like it's the title for the normal node fields (title/body) rather than a collapsed fieldset on its own. Moving all of them inside an "administrative options" which is layed out in a more logical (and compact fashion) would probably make it a lot simpler. - "Attachments" should probably be changed to "File attachments". - Your patch has messed up the UTF-8 in common.inc (the comment in mime_header_encode()). Check your editor settings please. - We should check for the presence of document.documentElement in the global JS killswitch. - collapse_auto_attach should be inside a isJSEnabled() - It seems you've undone the "undefined is undefined" IE5 compatibilty patch that you submitted a while ago. Finally, some code style stuff in the JS: - Always use brackets and separate lines for control flow, this avoids errors later. - You should put spaces around all operators, except between an operator and a quote. - Can you do for (var i = ... rather than var i; for (i = ... or does JS disallow it? The first looks cleaner. - You've used "php_style_naming" rather than "jsStyleNaming" in a couple of places. Sorry, I don't have time to test (exams!). Steven Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 20:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 20:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 23:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 09:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) ------------------------------------------------------------------------ June 5, 2005 - 11:21 : Dries For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.) ------------------------------------------------------------------------ June 5, 2005 - 18:51 : Dries Attachment: http://drupal.org/files/issues/collapsible.png (31.65 KB) I made a PNG with an overview of the "bigger picture". The overview identifies related work/patches and shows that collapsible page elements are somewhat of an enabler. Please take a look! ------------------------------------------------------------------------ June 8, 2005 - 12:05 : Thox Attachment: http://drupal.org/files/issues/collapse_1.patch (12.72 KB) Latest patch includes collapsing elements on the node creation groups (plus a new group around the input formats). I considered creating an "Advanced Editting" group around the top three groups (author, options & comments). I've not implemented that yet, as I'm very much liking the Node creation redesign [5] discussion. Screenshots: * admin/settings [6] * node/add/story [7] [5] http://drupal.org/node/15506 [6] http://www.flickr.com/photos/thox/18155964 [7] http://www.flickr.com/photos/thox/18155963 ------------------------------------------------------------------------ June 8, 2005 - 13:19 : Thox Attachment: http://drupal.org/files/issues/collapse_2.patch (13.48 KB) Added patch of comment.module and changed the node "Options" group to be called "Publishing Options". ------------------------------------------------------------------------ June 8, 2005 - 18:15 : stefan nagtegaal Damn, this is really nice! Works flawelessly on my localhost... Nothing more to say.. Very, very nice and good patch.
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Dries Status: patch I'd consider moving the collapsible form groups at the top below the 'Filter settings'. Right now, they look too much like subtabs. Regardless, this is a great patch. :) Dries Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 05: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 26, 2005 - 05: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 26, 2005 - 05: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 - 10:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 10: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 - 10: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 - 10: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 - 11: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 - 11: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 - 14: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 - 15: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 - 16: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 - 20: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. ------------------------------------------------------------------------ January 27, 2005 - 10:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 14:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 17:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 17:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 16:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 09:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 21:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 12:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 16:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 16:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 16:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [1] for more information. [1] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 23:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 05:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 06:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 05:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 05:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 05:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 05:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 06:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 06:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 11:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 12:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 13:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 13:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 23:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 18:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 19:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [2] library, especially when it's combined with a few extensions [3]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [4] is a good example of an application using javascript to add some nice features for users (uses the above library). [2] http://prototype.conio.net/ [3] http://taskthis.darthapo.com/javascripts/prototype-ex.js [4] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 21:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 22:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 06:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 09:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 06:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 10:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 11:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 13:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 13:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 22:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 10:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 10:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 11:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 14:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 19:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 20:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 20:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 23:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 09:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) ------------------------------------------------------------------------ June 5, 2005 - 11:21 : Dries For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.) ------------------------------------------------------------------------ June 5, 2005 - 18:51 : Dries Attachment: http://drupal.org/files/issues/collapsible.png (31.65 KB) I made a PNG with an overview of the "bigger picture". The overview identifies related work/patches and shows that collapsible page elements are somewhat of an enabler. Please take a look! ------------------------------------------------------------------------ June 8, 2005 - 12:05 : Thox Attachment: http://drupal.org/files/issues/collapse_1.patch (12.72 KB) Latest patch includes collapsing elements on the node creation groups (plus a new group around the input formats). I considered creating an "Advanced Editting" group around the top three groups (author, options & comments). I've not implemented that yet, as I'm very much liking the Node creation redesign [5] discussion. Screenshots: * admin/settings [6] * node/add/story [7] [5] http://drupal.org/node/15506 [6] http://www.flickr.com/photos/thox/18155964 [7] http://www.flickr.com/photos/thox/18155963 ------------------------------------------------------------------------ June 8, 2005 - 13:19 : Thox Attachment: http://drupal.org/files/issues/collapse_2.patch (13.48 KB) Added patch of comment.module and changed the node "Options" group to be called "Publishing Options". ------------------------------------------------------------------------ June 8, 2005 - 18:15 : stefan nagtegaal Damn, this is really nice! Works flawelessly on my localhost... Nothing more to say.. Very, very nice and good patch. ------------------------------------------------------------------------ June 8, 2005 - 19:37 : Steven Looking great... some notes: - I don't see how the "fieldsets with errors should open" works. I can see some code for checking that, but it is only invoked in a.onclick. There is also an unused variable collapse_action. Can you check this? It is an important feature IMO. - The administration options at the top are a bit weird... at a glance, it looks like it's the title for the normal node fields (title/body) rather than a collapsed fieldset on its own. Moving all of them inside an "administrative options" which is layed out in a more logical (and compact fashion) would probably make it a lot simpler. - "Attachments" should probably be changed to "File attachments". - Your patch has messed up the UTF-8 in common.inc (the comment in mime_header_encode()). Check your editor settings please. - We should check for the presence of document.documentElement in the global JS killswitch. - collapse_auto_attach should be inside a isJSEnabled() - It seems you've undone the "undefined is undefined" IE5 compatibilty patch that you submitted a while ago. Finally, some code style stuff in the JS: - Always use brackets and separate lines for control flow, this avoids errors later. - You should put spaces around all operators, except between an operator and a quote. - Can you do for (var i = ... rather than var i; for (i = ... or does JS disallow it? The first looks cleaner. - You've used "php_style_naming" rather than "jsStyleNaming" in a couple of places. Sorry, I don't have time to test (exams!).
Issue status update for http://drupal.org/node/16204 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/collapse_3.patch (13.08 KB) New patch fixing the things Steven mentioned. I've cleaned up collapse.js quite a bit and Steven was right that it didn't automatically expand the boxes. I've changed this now so that the groups start open when they contain errors, but can be collapsed manually after the page has loaded. See screenshot [1]. [1] http://photos14.flickr.com/18318326_03db6c9a33_o.png Thox Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 04: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 26, 2005 - 04: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 26, 2005 - 04: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 - 09:22 : Junyor FYI, window.addEventListener is not supported in Opera. ------------------------------------------------------------------------ January 26, 2005 - 09: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 - 09: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 - 09: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 - 10: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 - 10: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 - 13: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 - 14: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 - 15: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 - 19: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. ------------------------------------------------------------------------ January 27, 2005 - 09:54 : tangent 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. ------------------------------------------------------------------------ January 27, 2005 - 13:40 : moshe weitzman Re: collapsing sections with required fields. Keep in mind that a lot of fields are 'required' but they are hardly ever changed. `If you are an admin, you see lots of fields on the node/edit page such as Author which cannot be blank. This field is always contains a value already. You might want this admin section collapsed by default. Another example might be a taxonomy selector called 'Departments'. Perhaps the user always posts to the 'Marketing' department. Lets say that we re-instate an old feature whereby the system remembers your last chosen taxonoy terms. So this user might want to always collapse the taxonomy section and just accept default values. I hope that is possible even if the section contains a required field. The concern is not with required fields, but with *empty* required fields. Anyway, please consider this wrinkle in your design. ------------------------------------------------------------------------ January 27, 2005 - 16:00 : Steven I like the clean implementation. Just some notes: - Your method for changing the classname to ensure the CSS is not applied without JS is a bit convoluted. You can do this more easily by defining your rules as:html.javascript ... {} and doing: if (document.documentElement) { addClass(document.documentElement, 'javascript'); } function addClass(element, classname) { if (element.className.length > 0) { element.className += ' '+ classname; } else { element.className = classname; } } This will add the "javascript" class to the <html> element, and automatically enable all rules that select on that. - For matching classNames you should use: element.className.match('\\bclass\\b') to properly support multiple classes per element. - If we are going to include JS in drupal, we need to figure out some code style. While most of Drupal's PHP rules translate to JS, some don't really make sense. For example, Javascript uses 'studlyCaps' for variable and function naming. As we have to use that notation for predefined functions and variables anyway, it would seem to make sense to use that naming convention instead. - "cursor: pointer;" does not work in IE... you have to use "cursor: hand;" instead. The best solution is to use "cursor: hand; cursor: pointer;". CSS ignoring rules make this work on all browsers. ------------------------------------------------------------------------ January 27, 2005 - 16:24 : tangent Thanks for all the suggestions. 1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. 2. I tried to use the drupal code style where applicable but I agree that javascript should have its own code-style conventions. 3. As far as I know IE5 only supports cursor: hand while IE6 supports cursor: pointer (at least my version does). I would prefer to avoid adding non-standard CSS to drupal.css if possible. ------------------------------------------------------------------------ January 28, 2005 - 15:04 : Junyor Attachment: http://drupal.org/files/issues/fieldset_test5.html (4.08 KB) @tangent: If you change the third parameter for addEventListener() to 'false', it'll work in Opera, too. It's actually a bug in Mozilla that it works with the value 'true' in your script[1]. I'm attaching a modified version of fieldset_test4.html. Tested and working in IE 6.0, Opera 7.54 and 8.0B1+, Firefox 1.0, and Safari 1.2.4. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 ------------------------------------------------------------------------ February 5, 2005 - 08:38 : Steven "1. Your suggestion to apply a "javascript" class to html would result in the the fieldsets being collapsed if their DOM supports documentElement even though they may not support the addEvent implementation. I hope to do the class assignment as late as possible to eliminate the possibility of css being applied when the javascript is not functioning. " It doesn't matter when you do the class assignments, my point was that it would be much shorter than having to muck around with the class of /every/ fieldset. Surely you can check for the addEvent presence too? ------------------------------------------------------------------------ February 5, 2005 - 20:59 : tangent Changing the class of each fieldset is necessary each time the user clicks on the legend to expand or collapse it since I am using definitions in drupal.css to change the style settings of the fieldset (as opposed to restyling with js). This will allow a theme to change the style of fieldsets without having to alter the javascript. Further, I don't really like the idea of ".html .fieldset-expanded" selectors in drupal.css because it looks rather hackish. Finally, I have a dilemma over whether this feature is really wise. When testing the feature with a small test page it works great but in a live environment where pages take longer to load there is a delay (while the page is loading) before the fieldsets collapse because the js does not execute until the page is completely loaded. This flash is less than desirable and may be unnacceptable in some cases. The only workaround for this that I can think of is to integrate the feature fully into Drupal such that if js is detected fieldsets would be displayed already collapsed (unless they have a error field of course). It doesn't really seem appealing to go this route right now though. Thoughts? I am considering if the feature is more appriopriate as a theme feature. I have everything working and I am creating patches right now which will be attached shortly. Final functionality will be: * If javascript is available and all DOM requirements are met then all fieldsets will be collapsible (not optional) * If a fieldset has * a class of "collapsed" AND * the fieldset contains no EMPTY form elements that have a class of "required" AND * the fieldset contains no form elements that have a class of "error" then the fieldset will be collapsed after the page is completely loaded. * If a fieldset contains a form element that has a class of either "required" or "error" then it will ONLY be collapsible AFTER the user has entered a value in the form element. An additional note. Due to a bug in mozilla as of Firefox 1.0, fieldsets may not be styled as a block element. Specifically, if the "display" css property of a legend is altered it will render incorrectly so it may not be changed from inline to block (or none). This limits how collapsed fieldsets may be styled with respect to Firefox. This bug has reportedly been fixed since FF 1.0 but due to the widespread use of that version it is small consolation. ------------------------------------------------------------------------ February 6, 2005 - 11:14 : Dries 1. Make sure the patch applies against CVS. The version is currently set to 4.5.2. 2. Can we use this to simplify the settings pages? Right now, some settings live under 'admin/settings' while other settings live under 'admin/settings/foo' (eg. 'admin/settings/search' or 'admin/settings/throttle'). This is an artifact of our module system, so I bet this organization looks pretty random for anyone that is not familiar with Drupal's inner workings (we got used to it so take a step back and try looking at it from a user's point of view). I envision putting all 'simple settings' on one page. Combined with the collapsible form groups this might be a workable solution. If all forms are collapsed, you're presented an overview of all simple settings. Of course, that won't work for the 'complex settings' (eg. 'admin/settings/forum', 'admin/settings/profiles' and not to mention the filter settings on 'admin/filters') but nonetheless it might be a step towards a simpler model. One showstopping issue is that some of the settings pages (eg. 'admin/settings/search' and 'admin/settings/statistics) use several form_group() on their own. (If you haven't already, take a look at Jetbox One (easy to use demo: http://opensourcecms.com/index.php?option=content&task=view&id=169).) ------------------------------------------------------------------------ February 6, 2005 - 15:10 : tangent 1. Of course. 2. Of course. ;-) I've only added options to collapse some content creation fieldsets so far but I'll add options for the settings page as well. Is "General settings" expanded and all others collapsed a reasonable approach? ------------------------------------------------------------------------ February 6, 2005 - 15:23 : tangent Note that JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change the fact that collapsible element support must move into PHP to resolve the collapse delay issue. ------------------------------------------------------------------------ February 6, 2005 - 15:44 : Bèr Kessels JetBox uses tables and divs to markup their form layout (instead of fieldsets). If we go the generic markup route it would make styling easier (fieldsets are not well supported elements for DHTML) but would not change ... Yes, Taht was the exact reason, I wanted to revive the default Drupal Boxing/Div-ing nmethod. See Improve theme_box to make it better themeable and consistent with blocks [2] for more information. [2] http://drupal.org/node/15332 ------------------------------------------------------------------------ February 6, 2005 - 22:38 : Anonymous Actually, the "html.javascript something { ... }" trick is there to prevent the annoying flash of style. You set the HTML class immediately rather than on load (making sure to check if everything is supported). The CSS cascade then makes the elements collapse immediately. ------------------------------------------------------------------------ February 7, 2005 - 04:49 : tangent That seems like a a reasonable expectation but testing in Firefox and IE 6 indicates that it isn't the case. If the first command in the external javascript file assigns a class to document.documentElement (and that class is added to the selector for fieldsets) there is still a delay before the style is applied. ------------------------------------------------------------------------ February 7, 2005 - 05:23 : tangent Apparently this style delay only occurs when the reload option is used. When a form is loaded via a normal link click the fieldsets are collapsed as soon as they are visible (even without the html.javascript trick). This makes the issue very minor to me. I'll proceed with creating patches for my latest work and some form updates. ------------------------------------------------------------------------ February 8, 2005 - 04:47 : tangent Attachment: http://drupal.org/files/issues/drupal.dynamic-fieldset.patch (1.04 KB) I've pretty much finalized the javascript and css which handles this feature. The visual style could be better but I'd like to see the feedback on this before altering the group markup. Instead of overloading the javascript with doxygen comments (or any comments for that matter) I've instead chosen to make the code as terse and compact as possible in the interest of download efficiency. If it is decided that comments are needed/desired for the javascript files then I would vote for having a fully commented version and a "compacted" production copy. I found a perl script that compacts javascript pretty well but I guess we would have to seek permission from the author to be able to include it as a script tool. I also chose to split the javascript into 2 files. Once for generic dhtml functions and one for form specific functions. It would be desirable to have the ability to call a function like drupal_set_html_head_once($script_url) so that the script could be sourced in form_group() instead of including it globally but only have it included once. This doesn't seem to be an option presently though so they are both in drupal_get_html_head() for now. I will attach patches to modify the behavior of specific forms separately in case I guess wrong with some. Here is the first which patches drupal.css. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/dhtml.js (509 bytes) Here's the generic dhtml javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:49 : tangent Attachment: http://drupal.org/files/issues/forms.js (2.01 KB) Here's the form specific javascript file. ------------------------------------------------------------------------ February 8, 2005 - 04:51 : tangent Attachment: http://drupal.org/files/issues/common.dynamic-fieldset.patch (1.58 KB) Here's the patch for common.inc which adds the javascript files to head and updates form_group(). ------------------------------------------------------------------------ February 8, 2005 - 04:52 : tangent Attachment: http://drupal.org/files/issues/system.dynamic-fieldsets.patch (4.15 KB) This patch makes all form groups except "General Settings" on /admin/settings collapsed by default. ------------------------------------------------------------------------ February 8, 2005 - 04:56 : tangent Attachment: http://drupal.org/files/issues/upload.dynamic-fieldsets.patch (878 bytes) This patch updates the file attachment form group. ------------------------------------------------------------------------ February 8, 2005 - 05:07 : tangent Attachment: http://drupal.org/files/issues/node.dynamic-fieldsets.patch (1.17 KB) This patch makes the node.module option groups ("Authoring information", "options") collapsed by default. I am not certain this patch should be applied until it has been tested and is deemed appropriate. In particular, the "Options" group may need to be modified with each post for some users. Making some of these groups (I'm including the comment options group) collapsed and others expanded may look strange though unless the layout is changed. ------------------------------------------------------------------------ February 8, 2005 - 05:17 : tangent Attachment: http://drupal.org/files/issues/comment.dynamic-fieldsets.patch (745 bytes) Here's the patch which makes the comment options form group collapsed. Same comments as above. ------------------------------------------------------------------------ February 15, 2005 - 10:59 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset.patch (1.06 KB) It seems that the search module uses paragraphs inside of form groups instead of form item divs. The CSS I provided did not handle this scenario so here's an updated patch for drupal.css. ------------------------------------------------------------------------ February 15, 2005 - 11:47 : tangent Attachment: http://drupal.org/files/issues/drupal-css.dynamic-fieldset2.patch (1.13 KB) Sigh. Added a few more elements which are defined in fieldsets in new areas. ------------------------------------------------------------------------ February 15, 2005 - 12:38 : Bèr Kessels Can you not use .fieldset-collapsed * { display: none; } , Tangent? ------------------------------------------------------------------------ February 15, 2005 - 12:54 : tangent I'd love to use that but due to a Firefox bug (which I can't find right now) if the display property of a legend element is changed then Firefox renders it incorrectly. Following a change the legend would appear at the bottom of the fieldset following any other content in the fieldset. ------------------------------------------------------------------------ April 26, 2005 - 22:42 : moshe weitzman what is the status here? tangent? UnConed? is this ready for review? ------------------------------------------------------------------------ May 16, 2005 - 17:46 : magico any update to this? ------------------------------------------------------------------------ May 16, 2005 - 18:58 : Thox It would be nice if you changed all of the regular expression code to something a little more friendly and external such as functions for has_class(), add_class(), and remove_class(). I'm sure these would be used by any other future javascript implementation in Drupal. Bèr mentioned javascript optimisation (http://home.earthlink.net/~kendrasg/info/js_opt/) on the drupal-devel mailing list. One of the things I learnt from that is that you shouldn't put "var x = y" inside a loop - apparently it's very slow. Is there documentation anywhere for what kind of class names to use in CSS? I don't think "fieldset-collapsed" makes much sense. Simply "collapsed" would be far more appropriate, and the CSS file could reference it as ".collapsed" (or "fieldset.collapsed" if you really wanted). My problem is that I'm also using javascript to add functionality to Drupal. In my case it's autocomplete fields (using AJAX), so I don't need to worry about elements "flashing" on the screen. My problem at the moment is whether or not people think Drupal should use an external javascript library / API or make our own. I quite like the Prototype [3] library, especially when it's combined with a few extensions [4]. Since it's now part of Ruby On Rails, I imagine it's actively being developed. Incidently, taskThis [5] is a good example of an application using javascript to add some nice features for users (uses the above library). [3] http://prototype.conio.net/ [4] http://taskthis.darthapo.com/javascripts/prototype-ex.js [5] http://taskthis.darthapo.com ------------------------------------------------------------------------ May 16, 2005 - 20:23 : drumm If this gets added, something for general collapseability needs to be added simultaneously. I think this needs to happen to avoid anyone using form_group() outside of forms because the collapsible function only worked on form_group(). A good example of this happening in the past is the use of form_item() in displaying individual nodes of a few contrib modules. Off the top of my head I can actually think of many more uses for a generic collapsible themeable function (mostly for containing whole forms) than for collapsing form groups. ------------------------------------------------------------------------ May 16, 2005 - 21:11 : Bèr Kessels Drumms remark is also what we agreed upon on the meetings in Antwerp. ------------------------------------------------------------------------ May 25, 2005 - 05:43 : Steven I believe Thox is working on this patch now. It certainly needs to be updated to take advantage of the new JS apis in Drupal since autocomplete was committed. ------------------------------------------------------------------------ May 25, 2005 - 08:02 : Bèr Kessels Attachment: http://drupal.org/files/issues/collapsible_elements.pdf (119.12 KB) For reference, the notes from the meetings in Antwerp; ------------------------------------------------------------------------ June 1, 2005 - 05:35 : Steven Note that contrary to what we thought at the usability sprint, there is actually no HTML problem in using a fieldset outside of a form. In my opinion we should therefor use fieldsets everywhere for collapsible elements, it makes sure they look and act the same everywhere. ------------------------------------------------------------------------ June 1, 2005 - 09:34 : Thox I can code all of the behaviour described in the Antwerp meeting notes /except/ the behaviour of tabbing into a collapsed form_group. I can see no sensible way of coding such a feature in Opera. Opera does not let users tab through links on the page, so I cannot use the focus event of the expand/collapse link to trigger the javascript to expand the group like I can do with other browsers. Since I do not believe in using browser detection, I do not know any way of working around this. Also, it's not just Opera that is affected. The behaviour I made even involved a "hack" to make IE and Firefox both work. ------------------------------------------------------------------------ June 1, 2005 - 10:15 : Dries Then I think we should go ahead without tabbing. This is something that can be refined later on. Let's avoid browser-specific solutions at all costs (or as much as possible). ------------------------------------------------------------------------ June 1, 2005 - 12:32 : Junyor Users can navigate between links in Opera in several ways: 1) Using the A and Q shortcuts 2) Using spatial navigation (Shift+Arrows) 3) Using Ctrl+Up and Ctrl+Down Would these be sufficient for what you're trying to do? ------------------------------------------------------------------------ June 1, 2005 - 12:45 : Junyor Steven: According to the HTML 4.01 spec., FIELDSETs are for grouping "thematically related [form] controls and labels". In other words, semantically HTML does require that FIELDSETs are related to form controls. Is there any reason we can't use a DIV or SPAN elsewhere for collapsible elements? ------------------------------------------------------------------------ June 1, 2005 - 21:56 : factoryjoe Attachment: http://drupal.org/files/issues/fieldset_test_0.html (486 bytes) Even though the attached validates (a fieldset outside of a form), I don't believe that form elements can be used outside of the form tag. Therefore, by extension, it makes no sense, semantically, to use fieldsets in this way. I feel like this is overloading the fieldset in way that we should avoid. Divs should be used for logical divisions; showing and hiding a logical division makes sense to me as does showing and hiding a group of form controls. But the two are not the same and we shouldn't confuse the same markup for semantically different purposes. Fieldsets are for forms; divs are for logical divisions. We should abide by those definitions. ------------------------------------------------------------------------ June 2, 2005 - 09:23 : Thox As a common GUI widget, FIELDSETs can be seen everywhere - not just in areas where the user is needed to enter information. For this reason, I see no problem with using FIELDSETs . The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. ------------------------------------------------------------------------ June 2, 2005 - 09:33 : stefan nagtegaal "The only arguement I see against using FIELDSETs is that applying CSS to them is tricky across different browsers. " Indeed, which is exactly why I vote to use simple divs instead of fieldsets.. Remember about improving themability??? ;-) ------------------------------------------------------------------------ June 2, 2005 - 10:14 : Thox Attachment: http://drupal.org/files/issues/collapse.patch (7.98 KB) Here's a patch for collapsing FIELDSETs. I've made it work with all the fieldsets in the admin/settings page. I've tried to avoid any jumping effects that occur when groups collapse on the page load. The admin/settings page won't demonstrate this though, as all of the groups there are open by default. If a group contains an error then it will not collapse. If that same group was told to start collapsed, then the javascript will expand the group after the entire page has finished loading. ------------------------------------------------------------------------ June 3, 2005 - 13:19 : Dries The last patch doesn't seem to work for me (using Firefox) ... Not sure what is wrong. 1. Implementation-wise, I think it would be better to extend the existing form_group() API rather than introducing an extra function. 2. One of the driving factors of this patch is its applicability on the node submission/edit screen (and possibly the user edit screen). Can we modify the upload module to make the 'Attachment'-part collapsible? Can we extend core with something like menu_otf? (Ideally the path-stuff and menu-stuff would be grouped.) I think we should try so we can evaluate this properly. 3. Can we think of situations where one would want to collapse multiple form groups at once? How does this stack with the requirement to place the 'submit'-buttons outside the form-groups, for example? 4. Would it be a good idea to put all "simple settings" on one page? Eg. move the throttle.module, search.module, contact.module settings to the main settings page? Looks like this starts to rock. ------------------------------------------------------------------------ June 3, 2005 - 18:54 : Thox Attachment: http://drupal.org/files/issues/collapse_0.patch (4.91 KB) Attached is a (hopefully) working patch, including the extra collapse.js file. ------------------------------------------------------------------------ June 3, 2005 - 19:09 : Dries Attachment: http://drupal.org/files/issues/collapse.png (48.87 KB) Your last patch does not include the system.module changes. However, when I combine the system.module changes of your previous patch with your last patch, it works. :) Screenshot attached for those who want to see it in action. ------------------------------------------------------------------------ June 3, 2005 - 19:13 : Dries One more thing: the goal of collapsible page elements is to reduce the clutter and to help the administrator get an overview of the page. On the settings page all form groups are unfolded, which of course, defeats the goal of this patch. By default, all clutter should be hidden (not vice versa). IMO, this would be good time for the usability folks to step forward ... ------------------------------------------------------------------------ June 3, 2005 - 22:07 : Thox I'm away this weekend but I can update the patch next week. So far: - Fix the patch itself to include all changes (extra files & changed files) - Set the admin/settings boxes as collapsed by default - Integrate the collapsing code into the current form_group() function - does this mean adding an extra parameter? should it go at the end? ------------------------------------------------------------------------ June 4, 2005 - 08:47 : Dries Also: * Collapse the upload module group on the node form. * Think about how we can further improve the node form because that is what we created this patch for to begin with! I think we should reconsider how we deal with path aliases and integrate the ability to create a menu item for a page. That can be in a separate patch though. * Think about how we can further improve the settings pages. If we update 'admin/settings' to use form_group_collapse() it might end up looking weird, because it is the only settings page using form_group_collapse(). It makes for inconsistent behavior. As such, some extra refactoring/reorganization might be required. That can be in a separate patch though. (I prefer to merge form_group_collapse() and form_group() but it looks like we didn't merge form_textfield() and form_autocomplete() either. Not sure what is best.) ------------------------------------------------------------------------ June 5, 2005 - 10:21 : Dries For the node edit form, it might be better if the entire top-section ('Author details', 'Options', 'User comments') was collapsible in one go. (See also http://drupal.org/node/15506.) ------------------------------------------------------------------------ June 5, 2005 - 17:51 : Dries Attachment: http://drupal.org/files/issues/collapsible.png (31.65 KB) I made a PNG with an overview of the "bigger picture". The overview identifies related work/patches and shows that collapsible page elements are somewhat of an enabler. Please take a look! ------------------------------------------------------------------------ June 8, 2005 - 11:05 : Thox Attachment: http://drupal.org/files/issues/collapse_1.patch (12.72 KB) Latest patch includes collapsing elements on the node creation groups (plus a new group around the input formats). I considered creating an "Advanced Editting" group around the top three groups (author, options & comments). I've not implemented that yet, as I'm very much liking the Node creation redesign [6] discussion. Screenshots: * admin/settings [7] * node/add/story [8] [6] http://drupal.org/node/15506 [7] http://www.flickr.com/photos/thox/18155964 [8] http://www.flickr.com/photos/thox/18155963 ------------------------------------------------------------------------ June 8, 2005 - 12:19 : Thox Attachment: http://drupal.org/files/issues/collapse_2.patch (13.48 KB) Added patch of comment.module and changed the node "Options" group to be called "Publishing Options". ------------------------------------------------------------------------ June 8, 2005 - 17:15 : stefan nagtegaal Damn, this is really nice! Works flawelessly on my localhost... Nothing more to say.. Very, very nice and good patch. ------------------------------------------------------------------------ June 8, 2005 - 18:37 : Steven Looking great... some notes: - I don't see how the "fieldsets with errors should open" works. I can see some code for checking that, but it is only invoked in a.onclick. There is also an unused variable collapse_action. Can you check this? It is an important feature IMO. - The administration options at the top are a bit weird... at a glance, it looks like it's the title for the normal node fields (title/body) rather than a collapsed fieldset on its own. Moving all of them inside an "administrative options" which is layed out in a more logical (and compact fashion) would probably make it a lot simpler. - "Attachments" should probably be changed to "File attachments". - Your patch has messed up the UTF-8 in common.inc (the comment in mime_header_encode()). Check your editor settings please. - We should check for the presence of document.documentElement in the global JS killswitch. - collapse_auto_attach should be inside a isJSEnabled() - It seems you've undone the "undefined is undefined" IE5 compatibilty patch that you submitted a while ago. Finally, some code style stuff in the JS: - Always use brackets and separate lines for control flow, this avoids errors later. - You should put spaces around all operators, except between an operator and a quote. - Can you do for (var i = ... rather than var i; for (i = ... or does JS disallow it? The first looks cleaner. - You've used "php_style_naming" rather than "jsStyleNaming" in a couple of places. Sorry, I don't have time to test (exams!). ------------------------------------------------------------------------ June 8, 2005 - 18:54 : Dries I'd consider moving the collapsible form groups at the top below the 'Filter settings'. Right now, they look too much like subtabs. Regardless, this is a great patch. :)
participants (21)
-
Anonymous -
Bèr Kessels
-
Chris Cook -
chx
-
Dries
-
Dries Buytaert -
drumm
-
factoryjoe
-
Junyor
-
magico
-
mathias
-
moshe weitzman
-
Negyesi Karoly -
Scott Courtney -
stefan nagtegaal
-
Stefan Nagtegaal -
Steven
-
Syscrusher
-
tangent
-
Thox
-
Tim Altman