Remember state of collapsible fieldsets

I remember requesting the same feature for the Block bar module. I believe they are still working out a bug on that. Given our renewed interest in the user experience, I think it important that we take another look at this feature.

Moving the issue from User experience project to Drupal core usability component.

This seems to be handled by: http://drupal.org/project/fieldset_helper

After things approach a Release candidate phase (or earlier) this module can be migrated to Drupal 7.

I'm marking this as won't fix, since this feature request seems to be handled by the module I listed and therefore will not likely be implemented for Drupal 7.

forgot to add Usability tag

Contrib is where new core functionality often starts, so that in itself is not a reason to won't fix. It would be a very nice thing for core to provide out of the box so that any contib module can benefit from it too. Bumping this to Drupal 8 then

Retitling this and marked #176168: remember collapsed module sections a duplicate. Thanks cosmicdreams for the issue cleanups.

No problem, Trying to get that "inbox" cleaned up.

heh, holy cow. Cool probably cuts it.

Most of this patch is just moving some lines around.

Drupal.settings.q is something I probably could have used hundreds of times in contrib and custom sites already.

Drupal.storage, as added to drupal.js in this patch, is a very nice way to store and read such settings from the client-side. Modern browsers only, but that's perfectly acceptable exactly for features like this. Drupal.storage, itself, also shapes and introduces a common "interface" (similar to our Drupal interfaces in PHP), for which the API function signatures are set in stone, but the underlying storage functionality can be replaced (like any other JS function).

This patch only remembers fieldsets that should remain open, like on admin/structure/taxonomy/tags/add. It would be nice to remember which ones I want closed as well (hello admin/modules!).

But the patch works as advertised, and it's a good idea to have an interface around using the new window storage stuff in html5, so RTBC from me. Might want to add some developer docs, so they know roughly which browsers this is available for. Any interest in providing cookie-based backup storage?

#7: drupal.storage-collapse.7.patch queued for re-testing.

How about this? I abstracted out the things that each function had in common. In addition, I switched the arguments of .save, so key and bin stick together. Not sure if this is a good thing or bad thing, simply an alternate.

fixed two little errors.

I've completely revised the Drupal.storage code over in #910636: Use HTML5 features instead of GreaseMonkey and heavily advanced on it last night.

@dmitrig01: I think we should prepare such an API during D7 for contrib consumption and potential inclusion for D8. How about moving the current incarnation into Edge so we can join forces to come up with a bullet-proof and rock solid API for D8?

needs git patch

Looks like a lot has changed since the patch in #12 was made, but the essential point seems to be that we need to store $_GET['q'] so that Drupal.settings can access it later while evaluating in the javascript whether a fieldset should be collapsible. The approach seems to rely on localStorage to persist the collapsible state.

cross referencing with #1172670: Evaluate standardized usage of HTML5 Storage API through a library

This seems like something that could be implemented 100% client side with localStorage. That would make far more sense to me than messing around on the server at all.

@Crell cool, that was my instinct as well but didn't know it was right. I'll put this on my tracking list and try to touch on it next week.

This patch uses localStorage already. Please look at the latest patches first.

An improved version of the Drupal.storage helper exists in Dreditor. However, even though I authored it, I can't believe that we have to invent such a helper on our own. I'm sure that there must be something in latest jQuery core or some jQuery plugin that provides such a facility. For Drupal core, I'd like to see us using a standardized library.

That should be figured out in #1172670: Evaluate standardized usage of HTML5 Storage API through a library first. Thus, postponing on that.

Let's just use localStorage with no wrapper, let's talk about introducing more code when there is a working patch in here.

Is there a compelling use-case for this?

Closing since #1168246: Freedom For Fieldsets! Long Live The DETAILS.