Vertical tabs - no visual connection between the active tab and its content

I think it is a bug - if forces the user to continuously adjust the scroll - for example on every node going from Menu tab to others changes the height drastically (default install). For daily usage this is quickly going to be a huge PITA for content editors.

However this is not just a Seven problem so moving to system.

It would also be very cool if the vertical-tabs-list was equal to the height of the tallest pane (make it much easier to theme).

This does look nicer. Adding a tag for UX team to chime in.

Sure, ok. Based on the patch (which is a massive improvement in any regard) I'm not so sure about having the selected tab & pane gray and the inactive tabs/panes white - this seems around the wrong way - wouldn't "grayed" things normally be considered to be inactive?

Not sure about the internal borders - do we really need these. Mark Boulten also said something about borders + background = clutter (or something to that effect).

I attached a screenshot of another approach - what do you think?

Ouch, I just looked at the screenshot in #6 in another monitor and the gray is way to light.

This still needs quite some work, let me get back to this later. I like the chosen direction, however I would go with white active rather then dark active, also we need to see how this fits with the overall design of Seven, which for example rarely has such strong corners as this.

Since this creates a usability issue on the content creation, this is always considered major and potentiality critical.

subscribed! Will try to implement this in the morning

I already created an issue for the problem identified in #2: #867696: Vertical tabs make the whole page jump around (this is really irritating).

@#10 - those rounded corners on the active tab are going to be very hard if not impossible to implement using just CSS - it could be done with images I suppose, but do we really want to load it up with images (will probably run into other issues at some stage), be interesting to see what ideas come up for this in any case.

If there was a solution to jbrowns issue in #12 theming vertical tabs could potentially be a whole lot easier imo...

@jeff We had rounded corners before, we have rounded corners on loads of things? I see no problem in doing it with images if thats needed.

I'm sure it could be implemented with CSS3.

However, I am not sure it should have rounded corners. It would be good to see a mockup.

Something else that would be really cool is changing the active tabs with the mouse roller.

Bojhan, I'm not arguing design here - I'm pointing out the technical limitations of the technology (CSS rounded corners), even with images I cant really see a clean solution, its going to be ugly CSS - whats the point of rounded corners anyway - doesnt even fit with Sevens clean square lines.

@Jeff Thats why I want to prototype it? Design exploration is a phase every design should go through, vertical tabs for Seven didn't do that it jumped to an implementation. I am not taking a guess at rounded corners, I think they would fit in nicely with the rest of the design - Seven isn't squarish at all apart from the fieldsets.

So lets not worry to much about technical implementation and explore the idea, rather then pinning ourselves down on technical restraints before we even have a prototype (great designs fails, when you don't even attempt to explore). For something like this we need a patch to evaluate it in its context. I don't wish to battle the technical argument here, but we have rounded corners on a lot of things (tabs, toolbar, overlay ect) - lets not reject this exploration before we have even seen it.

Bojhan, you might be interested in having other people prototype your ideas for you, I am more interested in seeing nice clean code, so if I want to argue technical viability I will. We have quite enough messes to clean up in Drupal 7 already (Overlay, Toolbar, Seven...).

I'm not shutting down the concept either - please read my original comment - I actually said it will be interesting what will come of this. I was merely pointing out that this will be hard to do with CSS, which is how we've done almost all other rounded corners in Drupal 7 - a few instances where images are used are currently broken (Toolbar for one).

Well I hope someone will :) I hope you understand every design idea, is always challenged by a technical restraint - if I would consider each one before exploring a design, we would never make the many iterations needed to get to a great design, where that one might not even be close to the original idea.

First, great improvement Manuel!

A priori I agreed with Jeff's comment that light should be active, because the eye is drawn to bright spots. But as Jeff said, his screenshot does not have nearly enough contrast.

After playing around and going a lot darker than what Jeff had, I found that without the borders, it just doesn't have the impact of Manuel's original screenshot. I didn't bother with the colors inside letters, but I've attached a compromise between Jeff and Manuel's idea

Rounded corners: keep it as simple and clean as possible. If someone wants to add in images or use PIE or some such thing in their own theme, let them do it, but as a default option, it seems like bloat to me (and BTW, I've been using something similar to PIE for a while and get pure CSS rounded corners in IE, no problem, all versions).

Yeah - vertical-tabs-darker-inactive-tabs-with-border.png looks good.

I'm also a fan of vertical-tabs-darker-inactive-tabs-with-border.png

rick_deckard - the second screenshot with borders is most definitely better. More impact. You also hit on one of my major bug-bears in all of D7 theming - a lot of it looks like crap in IE so all these little touches like rounded corners the vast majority of users will never see...

One of the real bug-bears of this is when the .vertical-tabs-panes is longer than the .vertical-tabs-list - man I spent some time f'ing around with a pure CSS solutions (knowing all along just how fruitless that would likely be...) anyway - what about ye-old faux column?

I could attach the patch for this if you want to test it.

dammit, wrong screenshot (not cropped) oh well...

Patches please :) I like jeffs last screenshot, even the 1 pixel rounded corner. The only problem to fix then is how to diffrentiate between tabs, as they are now a big gray area.

screenshot from #25:

How about a different approach with gradient tabs and a faux column on the main div wrapper. The patch also sets the width of the UL to 240px which I think is reasonable enough, I see no real reason why this has to be a percentage (core vertical-tabs.css has it as ems). This would need RTL work but we can see the idea here in any case.

Theres two images - fc.png and tab.png which both go in seven/images.

I don't think gradients should be introduced to Seven. It does seem that the general approach is good though: making the full vtabs area background white and tint the inactive tabs (instead of overlaying white areas on top of an overall gray area).

Will have a closer look a bit later, but it seems a reroll of #28 using bottom-borders instead of gradients is the next iteration we'd like to see?

@yoroy Yes. while you are at it, try inverted borders (so white instead of dark) too.

Just a friendly reminder that we are trying to get Drupal 7 out the door and that UI freeze was 9 months ago. So the only thing we should be doing here is the minimal necessary to fix the bug.

Thanks!

The minimal here to fix the bug is to :

1) Fix the visual connection between the active tab and the pane (usability error)
2) Make sure the fix adheres to Seven styling, to not break visual identity this late in the game.

I hope yoroy's patch will do that, I think we are really close.

Seven does have gradients - on the buttons - the color values for the gradient I used are pulled strait from buttons.png with a minor adjustment because we need more vertical expansion (button.png is only 80px high). This is actually where I got the idea from - because its consistent with an existing style in Seven.

Borders are kind of problematic - see the screenshot - the only way I can see to solve this is 1) the last tab never has a border-bottom or 2) the UL has a margin bottom so it never touches the .vertical-tabs wrapper.

Removing the background images in the patch from #28 was almost enough. I looked at some variations for borders but here a darker gray seems to work best.

no border:
http://img.skitch.com/20100911-ttk4p3usun5wa8i5y5m6g2rxfb.jpg

white border:
http://img.skitch.com/20100911-gwjtnk9he2qscc3ebm3qnpjhi4.jpg

In this patch:

I content that #34 fixes the bug that this post attempts to address and could be marked RTBC

however, still looks a but odd if the pane is longer than the tabs:

Its kind of a bit odd when you have the fieldset longer the the UL, big white space below and no border on the last tab.

I've attached a patch which I was hacking to together at the same time which is kind of similar but keeps the faux colom and does it with border-top instead - either way I think we're on the right track and getting close.

For this is patch to work you need this image: http://drupal.org/files/issues/fc.png

bot?

I don't know why it didn't report back, but the test seems to have passed. (Click on the "View details" link)

Option 3: Don't mind about the white space pointed out in #35/#36, I don't think it is confusing. Just add the negative margin to avoid the double-border-bottom?

I can't get this patch to apply - head is still at 1.6 so I don't quite get it, grrr.... Sounds like a brilliant idea with the -neg margin fix for the double bottom border.

Tested both patches #36 and #39
they both look good and behavea as expected

tested in latest firefox, chrome, Opera, IE7
someone please test with IE8 I don't have available at this time

in IE7 the top 2 tabs you need to hover over the text in order to be able to click the tab
just hovering over the tab box does not do it (this behaviour is because of this patch it was not there before)

They both work OK with IE8
so I guess we can mark this a RTBC

If something is broken in IE7 because of the latest patch it would need work. Can someone confirm #44?

wait ... what happened to

in IE7 the top 2 tabs you need to hover over the text in order to be able to click the tab
just hovering over the tab box does not do it (this behaviour is because of this patch it was not there before)

is this no longer an issue?

crosspost ... needs review is fine :)

GiorgosK can you post some screenshots of your results in IE7, especially with the last tab selected, I applied the patch manually and am getting some odd results in IE7 - when the last tab is selected mystery padding/margin appears below the last tab (screenshot 1). Any chance you could roll a patch off your system, the one in #39 won't apply for me.

I think we should try to solve the link problem in IE7, its very odd.

Showing some mystery padding or margin when the last tab is selected in IE7...

+++ themes/seven/vertical-tabs.css  12 Sep 2010 12:21:17 -0000
@@ -30,38 +32,47 @@ div.vertical-tabs ul li.vertical-tab-but
+div.vertical-tabs ul li.last a,
+div.vertical-tabs ul li.last a:hover {
+  border-bottom:1px solid #ccc;
+  margin-bottom:-1px;
 }

Keep meaning to add - needs white space after the colon.

Powered by Dreditor.

Sorry guys for the "reviewed & tested by the community" but I thought IE7 was not a big deal to worry about since IE8 is out
but I was wrong

@Jeff Burnz
again the mystery padding on IE7 I did see exactly what you see but did not think it was a big deal either
thus I don't think you will need any patch from me (I get exactly what you get)

do we need worry about IE6 ??

After a lot of hacking and testing I got at least one of the bugs out of IE7 - the hover bug where for strange unknown reasons the tabs above the selected tab loose display: block; on the anchors (that's the best I can describe it...).

Still have some strange padding/margin bottom on the last tab when its selected, but I've lost patience with IE7 so this is my last shot. Good luck.

BTW - this patch also moves the font sizing for vertical tabs in styles.css to vertical-tabs.css - seems like the right move.

#54: seven-vertical-tabs-faux-column-with-borders-4.patch queued for re-testing.

Looks like I've been able to solve the IE issue so this is really close now.

Also added better support for focus styles (focus style will apply to the selected tab also), and removed the line spaces between declarations, cleanup up some other redundant cruft.

The patch needs this image in seven/images http://drupal.org/files/issues/fc.png

OK scrap the selected focus styles, that didn't work so well after all, my bad, this is the one, still needs the image fc.png.

Can we have screenshots? I am going to be out of town for 4 days soon, I will give it a final review.

latest patch works as advertised
in Safari 3.1, Firefox 3.6.10, Opera 10.62, IE7, IE8, Chrome 5, Chrome 6

basically the only problem was IE7 thus marked RTBTC

Ehm, no.

Heres a couple of screenshots - its the same same as before (#36) except it now looks like this in every browser (fixes the weird padding issue in #49) and the display: block; issue also (originally fixed in #49).

So now IE7 has decided it hasLayout and doesn't need some padding bottom on the textarea.. sheesh, dang IE7!

This is good to go, someone just check that theres a gap between the Tips and the Vertical Tabs when you add a Basic Page with no added fields - this is where I ran into a hasLayout issue where IE7 collapsed the margin top on the vertical tabs wrapper (so they touched).

Looks good ... RTBC++

Checked in IE6,7,8 FF4, Safari5, Chrome 6

Good, still feeling that the rounded corners are necessary for this to feel part of Seven. Given that the people in this issue are disagreeing to implement this and its major to get this in early - I am going to let it slide, open a new issue or followup.

Committed to CVS HEAD. Thanks.

Something went wrong while committing this patch I think. The vertical tabs have no background-color in their normal state anymore. Screenshots attached.

It seems as if fc.png, the faux-columns background-image either wasn't committed properly, or my checkout command

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout -P drupal

somehow is wrong.

At http://drupalcode.org/viewvc/drupal/drupal/themes/seven/images/ it doesn't show up, too.

EDIT: see #57, where Jeff notes that the image needs to go in too.

Just needs to get the image from #57 committed, too.

Oops. My bad! Committed image to HEAD, too.

That's funny we need an image here rather than just a CSS rule. Huh.

Oh. Dries committed this originally. LOL. I am officially losing my mind. ;)

Yes, and we decided to fake it - its a called a Faux Column, which is a very old technique but a goody.

I'm counting the days until we finally switch to git, so adding/removing files in patches becomes painless...

Reopening this issue based on a bug found in #925350: Vertical tabs broken.

@32 - yes thats basically it. Visually they look good - core does the focus styles with outline and underlining the link, Seven uses background color on the tab. Non-selected tabs are coloured gray, while the selected tab is white - the same color as the panes (to visually connect an active tab to its pane).

For me the automagic first selected field works, as does pressing enter again to go back to the tab. I can see small issue with Seven in this regard because it does not highlight the active tab on focus/hover, we should look at that in the Seven queue. (@33, http://drupal.org/node/925350#comment-3523258)

Everett #925350: Vertical tabs broken was just closed after you re-opened this issue. Was the problem fixed or not?

What do we need to do to close this issue?

In Seven, is there a highlight on the active tab on focus/hover?

No there is not, but is that a problem - why do we need to highlight the active tab on focus/hover?

@Jeff

So that keyboard only users know where the focus went when they hit that tab. "highlight" is probably a bad term. There just needs to be visible indication that the element has received focus.

OK, I can see how that would aid the cognitive flow (don't make me think - where did the focus go), so I would be in favor of a focus style being added. However I prefer not to have a hover style, I can't see that it would help in the same way and could be an unnecessary distraction.

@Jeff

Agreed, I think that a focus style is sufficient.

Ok, can someone write up a patch for this then? If we just need to add a focus element it sounds like most folks won't even notice it. A very simple css change from the sounds of it that would hope could get brought into point release if we can't get it in before D7's release.

maybe I'm missing something, but I see a visual highlight on hover ... and here is the style definition from seven/vertical-tabs.css:48

div.vertical-tabs ul li.vertical-tab-button a:hover,
div.vertical-tabs ul li.vertical-tab-button a:focus {
  background: #d5d5d5;
  text-decoration: none;
}

Unless I'm missing something, we can close this issue.

...but see what comes right after that...

div.vertical-tabs ul li.selected a,
div.vertical-tabs ul li.selected a:hover,
div.vertical-tabs ul li.selected a:focus,
div.vertical-tabs ul li.selected a:active {
  background: #fff;
  border-right-color: #fff;
  border-top: 1px solid #ccc;
  outline: 0;
}

This means the selected (active) tab won't highlight on focus or hover.

this patch gives the active tab the same visual hover/focus state as an inactive tab. Personally I find it jarring when I click on a tab to make it active and it doesn't change to a white background (indicating that it is the active tab) until I move the mouse off the tab ... but I can live with it.

Here is a vid: http://screencast.com/t/yoQl2iCzA

+++ themes/seven/vertical-tabs.css	18 Oct 2010 01:13:09 -0000
@@ -59,6 +54,13 @@ div.vertical-tabs ul li.selected a:activ
+div.vertical-tabs ul li.selected a:hover,

We don't need a hover style, just a focus style - we are replacing the visual queue of the mouse pointer.

Looking at this now I remember why I set the focus style to white, no outline etc, because "when I click on a tab to make it active and it doesn't change to a white background" is unacceptable. In certain browsers that background will stick until you click somewhere else - clearly not a good solution.

What if we just take away the outline: 0; ?

FWIW I am still on the fence if this is actually an issue. I can see the outline/focus is an issue for links in content, or where its non-obvious where the focus has gone (big page jumps for example to links with no outline or focus is a serious wtf), however in this scenario its pretty clear you are tabbing up and down a list.

Powered by Dreditor.

It is obvious, arguably, that you are tabbing up and down a list. Is it obvious if.

1. First tab is active
2. user tabs to the first tab from its immediate sibling, before in the DOM.

Since the user is tabbing into the list of tabs they may not know where the focus has gone.

I've applied this here http://drupal7.dev.openconcept.ca

And then removed the outline as specified by Jeff.

The css for the keyboard only user still seems to be behaving differently than with the mouse.

@bleen18 do you have any additional thoughts on this?

I do think this is something that could potentially get into a point release after the 7.0 release because it doesn't actually affect anything really except keyboard only users. Can't see any reason to object to this being cleaned up afterwards as a bug.

However, would be better to get it in beforehand.

@Bojhan, any usability comments here?

Since the user is tabbing into the list of tabs they may not know where the focus has gone.

AHA, yes, very good point, another gem of an observation by Everett.

Just as an aside, this isn't a critical issue. Users can press tab a couple of times find the focus, reverse tab and likely figure out where the focus has gone when it disappears. But, this falls into the 'don't make me think' category. Users shouldn't have to guess at, or use cognitive cycles to determine, where the focus has gone.

@mgifford: I cannot login at your test site so I cannot see what is going on. In my tests, the using keyboard only does act differently but only because chrome uses voodoo magic to highlight the element that is in focus with a blow glowing bit of glow-i-ness.

can you either make an account on your testsite and link directly tt a page with vtabs or can you create a screen capture video so we can see the difference between mous and keyboard

Please create a new account and I'll give you admin access http://drupal7.dev.openconcept.ca/user/register

@mgifford

Would you be able to setup a guest account and give the authenticated user access to something that requires vertical tabs?
user: guest
pass: guest

Done. Then folks can look at this page here - http://drupal7.dev.openconcept.ca/node/add/book - that has one vertical tab.

@Manuel Garcia why did you start from a different patch from @bleen18's in #84?

Did you re-roll the patch because it was ugly? That's ok, but I just want to know what's changed and what we're testing for.

Agree with #96, I also think this might be one of the very few non-ugly ways of dealing with this. Indeed the issue pointed out in #96 regarding the broken visual connection is pertinent, and there's no easy solution to this, so the "underline" compromise seems reasonable from both design and usability perspectives.

Can anyone provide images?

Thanks, looks RTBC then.

Committed to CVS HEAD. Thanks.