I suggest we improve the vertical tabs with forms with a large number of tabs (core modules alone when all enabled, makes a total of 8 tabs appear on node form).
I'm attaching a patch which does the following:
- After a tab is clicked and its pane/fieldset is activated, the patch adds a check to see if at least 50% of the pane is visible.
- If not, it scrolls to the pane (with an added offset of -20, which I believe makes the final effect easier on the eye).
Comment | File | Size | Author |
---|---|---|---|
vertical_tabs_scroll-01.patch | 854 bytes | AmrMostafa | |
Comments
Comment #1
webchickMarking as a patch.
Comment #2
chx CreditAttribution: chx commentedComment #3
kkaefer CreditAttribution: kkaefer commentedNot sure if that's really a good idea. The jump could also confuse users. I had something similar in slideshow.module (it scrolled up so that the entire image is visible after you clicked 'next'), but decided to remove it because it annoyed me and confused users (I watched them struggle when using the slideshow).
Comment #4
Bevan CreditAttribution: Bevan commentedVertical tabs is not really designed to use with large numbers of tabs (more than 7±2) or with large panes (longer than the viewport). By adding this patch we are suggesting that this is okay; It's not. I'm inclined to mark this as "Won't fix". Some documentation about the practical limits of vertical tabs would be better.
Comment #5
AmrMostafa CreditAttribution: AmrMostafa commentedBevan, that usability concern is exactly why I started this issue, I now realize I misunderstood an important part of vertical tabs as I was under the impression that contrib modules would be adding their options/settings which span across multiple node types to the same vertical tabs group ('additional_settings'). Maybe that's because it's how core currently does it.
I think others could very easily misunderstand vertical tabs too. We definitely need a guideline. "Don't use vertical tabs for X or more tabs" doesn't seem to be enough, because there isn't a single point where a module author or site administrator can control that number. Every form in Drupal is collectively worked upon by different modules. Though it's probably an issue only for popular forms, like the node form.
I'm setting this to Won't fix, but I hope we continue the discussion either here or in a different (new?) issue.
Comment #6
Bevan CreditAttribution: Bevan commentedI agree. I hadn't been following the implementation very closely and this will probably be an issue, in the same way that collapsible feildset abuse is an issue in several contrib and core UIs. See http://groups.drupal.org/node/21604 for some thoughts on this.
Comment #9
cosmicdreams CreditAttribution: cosmicdreams commentedWas previously set to won't fix but a re-test in december changed it's status. switching back to won't fix as the logic still seems sound.
Comment #10
fietserwinCross linking to a similar issue (that hopefully does get accepted): #1171172: Changing vertical tab resets the vertical scroll position of the page