use jQuery to hide user picture settings when disabled
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | javascript |
| Category: | feature request |
| Priority: | normal |
| Assigned: | dww |
| Status: | closed |
as per http://drupal.org/node/144859, i'm on a mission to make the admin/user/settings not so huge and difficult to use. a rather simple way to simply things is to use a little jQuery to hide all the picture-related settings if that radio is set to "Disabled" (which is true by default). i already learned enough jQuery to do this for a very similar sort of usability enhancement to the signup.module, so i figured i'd put my meager jQuery chops to good use for core, too. ;)
while i was at it (since i had to touch all those lines, anyway), i also re-formatted all the picture-related form elements to proper code style (multi-line array, not giant blobs of goo).
also of interest, i added a new class to system.css called "js-hide", which is automatically hidden via CSS on page-load when JS is enabled (using the html.js class). this way, the settings can be hidden immediately via css, and only expanded via jQuery when you touch the radio, to avoid flicker on page load, etc. this is the recommended approach from Steven, and when i was doing this for signup.module, he said we should just have such a thing in core. assuming this gets committed, now we do. ;) (i notice Steven added a html.js .no-js for the teaser-splitter thingy, which does basically the same thing, but that's used for printing text that should only display when JS isn't enabled, and i didn't want to mix up these two uses... if that's crazy, and i should just re-use "no-js" for this, it's easy to fix).
p.s. the good news is that this patch applies cleanly (with offset) even when you apply #144859, so there should be no conflict between these two for testing or committing. ;)
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| user_pictures_js.patch.txt | 6.34 KB | Ignored | None | None |
#1
Steven's down with the js-hide .css. however, he had some minor gripes with the elegence of user.js. here's a slightly more simple/clear version.
#2
also, lest anyone think the disappearance of the completely redundant and useless "Enable picture support." description was an accident, that was definitely intentional. ;) so, for consistency, here's another (final?) patch that nukes the same silly description for "Enable signature support"...
#3
Nice. I was actually thinking about exactly that, the other day.
What does the
[['hide', 'show'][this.value]]mean in:<?php$('div.user-admin-picture-settings')[['hide', 'show'][this.value]]();
?>
I'm not familiar with that syntax. I guess it calls hide() or show() depending on the value of value-attribute? Interesting. :)
<?php+ // If JS is enabled, hide all the settings on page load via .css
+ // using the js-hide class so that there's no flicker.
+ $form['pictures']['settings'] = array(
+ '#prefix' => '<div class="user-admin-picture-settings js-hide">',
+ '#suffix' => '</div>',
+ );
?>
Wouldn't that hide the form when JS is disabled? The class is always generated, regardless of whether Javacript is enabled or not. Also, I don't see where the data gets shown()? The JS snippet above only shows the data when you _click_ on the radio-buttons. Shouldn't we also check this on page load (in a read() function)?
Sorry if these questions are abvious -- I'm still learning jQuery. ;-)
#4
*Subscribing*
This is pretty interesting... We can use this at several other places too..
I'll look how this patch works of Derek, and I'll go ahead and sprinkle it through the rest where this could be used...
Very nice approach to unclutter things a bit...
#5
replies to Dries's questions:
I guess it calls hide() or show() depending on the value of value-attribute? Interesting. :)
yup, that's the idea. pretty self-documenting, IMHO. Steven likes it this way, too.
Wouldn't that hide the form when JS is disabled? The class is always generated, regardless of whether Javacript is enabled or not.
that's the miracle of the html.js class. it's *only* used when JS is enabled. so, this part in system.css:
html.js .js-hide {display: none;
}
means that things wrapped in the "js-hide" class are *only* hidden if JS is enabled. which is exactly what we want. when JS is on, we hide (via .css, not JS) on page load. when JS is off, we display everything.
Also, I don't see where the data gets shown()? The JS snippet above only shows the data when you _click_ on the radio-buttons. Shouldn't we also check this on page load (in a read() function)?
argh, i got this right in signup.module, but forgot it here. ;) we just want to only conditionally put on that js-hide class for page load if the radio is defaulting to off. i mistook the default when the settings page is new with the default value if you had already saved it enabled. ;) this is a trivial change, stay tuned for a reroll.
#6
there, much better.
#7
Derek: What did you actually changed inside user.module? (to me it looks like you just made the lines easier to read by giving each FAPI property a line of itself, am I right or missing something?)
#8
Stefan: in the diff against user.module, you missed:
- '#description' => t('Enable signature support.'),...
+ '#prefix' => '<div class="user-admin-picture-radios">',
+ '#suffix' => '</div>',
...
+ drupal_add_js(drupal_get_path('module', 'user') .'/user.js');
+ // If JS is enabled, and the radio is defaulting to off, hide all
+ // the settings on page load via .css using the js-hide class so
+ // that there's no flicker.
+ $css_class = 'user-admin-picture-settings';
+ if (!$picture_support) {
+ $css_class .= ' js-hide';
+ }
+ $form['pictures']['settings'] = array(
+ '#prefix' => '<div class="'. $css_class .'">',
+ '#suffix' => '</div>',
+ );
...
look more closely at the patch, searching for those lines, to see the context.
#9
Works as expected!
No errors in FF/Safari, and works very straight forward.
If this gets in, I'll volunteer to make use of this at several other places too..
#10
Committed! Thanks.
#11
cool, my first jQuery in core. ;) see, i'm not such a CLI ludite, after all... *lol* thanks, y'all.
#12