Collapse the input format into a fieldset even if there is only a single input format
Amitaibu - September 3, 2008 - 20:39
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | filter.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Amitaibu |
| Status: | won't fix |
Description
The need is to clean a bit the clutter in the form.
#125315: Textarea with input format attached might make this patch obsolete.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| input_format_1.patch | 2.75 KB | Idle | Failed: Failed to apply patch. | View details | Re-test |
| Snap1.png | 15.21 KB | Ignored | None | None |
#1
Patch failed to apply. More information can be found at http://testing.drupal.org/node/14038. If you need help with creating patches please look at http://drupal.org/patch/create
#2
Let's see if this will make the Bot happy :)
#3
I don't think #125315: Textarea with input format attached will make this patch obsolete, but it might break it. This is because that issue has veered off from a usability improvement to a technical way to attach input-formats directly to textareas without any changes to the UI.
This patch still applies, but I do not get the promised behavior. See the attached screen shot.
Finally, the patch uses occasionally \r\n newlines in stead of \n.
#4
@maartenvg ,
Sorry, I've omitted an important detail - you should visit
admin/build/themes/settingsand Enable theAlways hide the filter tips in a collapsible fieldsetNew patch removes incorrect line endings and white space.
#5
Ah ok. In that case: it works.
I'm not so sure whether
admin/build/themes/settingsis such a good place to this, because why do we want this to be theme-dependent. It definitely wasn't the first place I looked. Perhapsadmin/settings/filteris a better location, because it influences the filters?#6
I think we could make this standard behaviour - it definitely doesn't require a setting.
#7
[sorry, double post]
#8
Patch adds behavior without any settings.
#9
Removed un-necessary
else#10
This patch doesn't seem incompatible with neither #125315: Textarea with input format attached nor #304330: Text format widget.
Please also remove the
ifand the comment:<?php// Multiple formats available: display radio buttons with tips.
?>
#11
Hum. No.
You have to keep the if/else and put the fieldset outside it.
#12
Followed Damien's comment #11 and moved fieldset out the if/else.
#13
Reroll to apply cleanly.
#14
The last submitted patch failed testing.
#15
Re-roll after pfir gone wild :)
#16
Works like a charm now. Seeing that at least 2 people have looked at it, and the fact that the patch is tiny, I've marked this RTBC. Let's see what the core maintainers think about this feature.
Summary of the patch:
The result of this patch is this: http://drupal.org/files/issues/Snap1_57.png (but collapsed by default). This improves usability because the screen is less cluttered by input format information which might be extremely long when using more filters. Especially if there are more than 1 text areas with input formats attached.
#17
The last submitted patch failed testing.
#18
Thanks bot, I found a small bug: no need for validation callback if there is only 1 input format, because in that case there are no radio buttons to check.
I ran some tests, and this time they run fine. Let's hope the bot agrees.
#19
Personally, I'm not convinced this is an improvement. What is the rationale for this? It seems to be missing from this discussion.
#20
The reason behind the patch might not be noticable if the input format appears only once in a form -then it probably doesn't bother very much. However, when we have a form with several fields - a user will see multiple instances of the open input format fieldset. In that case I think having a collapsed fieldset is better then an open one in order to remove the form clutter and the annoyance of the same duplicated explanation about the input format.
#21
It's an usability improvement, because it seriously decreases visual clutter in the following situations (or combinations thereof)
- when there are multiple textarea's with input filtering enabled
- when the visible input format has a lot of filters (I've seen sites with 8 or more lines of input filter descriptions)
- when there are more open fieldsets that have a higher attention priority than the input filters. e.g. the node/add/* pages with menu- , path-, workflow fieldsets, etc.
So more or less the same reason to collapse it when there are more than 1 input format to choose from.
#22
Hm. I'm sorry, but I think I am going to won't fix this in favour of #304330: Text format widget, where members of the usability team are re-working the input format interface entirely.
The overall goal you have here -- make this more consistent so it looks the same for users regardless of how many formats they have access to -- is a very good one. But the approach taken at the other issue is http://img.skitch.com/20081028-d5mkx7g31h382h9xq1p7ktyeb6.png which I believe also satisfies this goal, and is a bit nicer looking visually.
I really encourage you though to chime in over there since it'd be awesome to combine efforts on fixing this nasty part of core once and for all! :)