Vertical tabs style update

This patch replicates the visual style while keeping the existing class names. I assume implementing the awesome new naming conventions like in the Seventy Eight sandbox is beyond the scope of this issue.

This seemed to translate well except as shown in the second screenshot where the pane is a shorter height than the tabs, even obscuring the visual "pathway" into the selected tab.

not ok here:

The corner issue is when the element with border radius also has a background color, and this now has the fix for that which is overflow: hidden; (Ryan has this is the prototype, I didn't realize why at first).

On the other issue, what was done in the previous design was using an image for a background and border (and a second one for rtl). We need to solve this a smarter way, I experimented and didn't come up with a solution.

This patch fixes the corners and adds rtl. I didn't delete the 2 images since I am unsure what's causing some weirdness with my setup with applying add or delete images.

Coincidentally, in a recent commit #1978036: Clean up css in vertical tabs I had removed a bunch of qualified element selectors, and we could further refine those (but not here since it involves the files in core/misc) but may be rewriting anyway.

Screenshot with fixed corners.

I'm setting status to needs work for the issue where the pane is a shorter height than the tabs as shown in #1. Although I hadn't resolved this, I wanted to submit what I had so far.

Edit: oops, crosspost. Thanks Bojhan, yes I'd love to get Ryan's eyes on the bkg issue.

Dealing with that issue only with css (and I would really love to do that without js) I assume is pretty difficult. It needs some time...

I have a solution. The only visual change to the design is the formerly darker background color now matches the right pane and selected tab. Then the border is now on both the pane and the tabs, overlapping.

@Bojhan, that was the sacrifice to not use an image, which for a background color and border is pretty archaic. What we see on the left is a ul that is only as tall as the tabs, and under it is the background of the entire container. I do agree it would be somewhat better to have visual difference from the right, although it doesn't actually break the tab metaphor.

Don't ask me why, but adding clearfix to the pane container fixes it. Hooray!

I've made a conscious decision not to add the clearfix class but instead replicate it in the seven CSS. It's so tied to the current styling I wouldn't like this to spread to other themes.

Fantastic! I had tried overflow: hidden; and it didn't work. This patch completes the RTL.

This looks nice! Two points:

1. Last active tab doesn't get a drop shadow. Seems because that shadow is applied to the (in that case non-existent) tab below the active tab. Bug, feature or conscious design trade-off?

2. The screenshots in #13 suggest a darker color for the link/title in the active tab. I didn't see that while testing (Firefox, OSX). Not sure what's intended.

#15 + #16,
1. Yes, the prototype does apply an inset box-shadow to the following adjacent sibling and IMO this looks like a rounded top on the element below, rather than a shadow under the tab itself. After testing, I like the shadow on the tab itself better (which looks like its shadow and also provides a shadow on the last item). If we clarify the intention of the design (Lewis?) it will be simple to move the box-shadow to each tab, afaict.

2. FF is interpreting the :focus styles differently. These link styles might be overly complex (plus combined with previous link css) as Bojhan touched upon in #5.

Applying an inset shadow on the following tab instead of a drop shadow on the active tab is a technical requirement of the design. We can't apply a box-shadow to the active tab without it overflowing out into the content panes. Maybe we can work out some kind of fiddling to get a shadow on the last tab if it is active but I wouldn't expect a shadow to appear above the tab, that would be reversing the direction of the light.

We do have the negative spread radius technique for a shadow on one side. The negative spread has to be equal to or greater than the blur to hide the shadow leaking on the sides not wanted. My error thinking we could use this as our shadow was I had only tested on the last tab. The other tabs' shadows using this technique are covered up by next tab under them!

Here's a screenshot of this on the last selected tab (doesn't work on the link, but on the li). It's a different looking shadow as I described in #17. If we are ok with the shadow on the last being different, here it is.

Compared to the existing shadow.

@echoz Can you post the code for this? I'm struggling to see how we can apply this shadow without affecting up the other styling.

@LewisNyman

.vertical-tab-button.last.selected {
  box-shadow: 0 5px 5px -5px hsla(0, 0%, 0%, 0.3);
}

I can make this shadow work on all selected tabs (li items) by giving the li items position: relative; and the selected varient a z-index value, so the shadow does fall on top of the tab below it. The only conflict then is the focus styling when :active (on click) getting partially covered since that is on the anchor, and becomes behind the li. I suppose it's possible to build up a stacking order including the anchor tags, but what a mess. Ideas?

This patch now has the shadow working on all selected tabs (li items) including the :focus and :active states, which work on the li rather than the anchor tag. The focus style does work on clicking above and below a selected tab.

I've also further reduced the selectors in both the core/misc and seven versions of the vertical-tabs.css (+ rtl).

Wow, it looks like RTL vertical tabs do not work *before* applying the patch! After testing with a RTL language (I get like you do, it's english but right aligned text and punctuation), I find that neither of the RTL stylesheets (core/misc or seven's) are being recognized at all (testing obvious overriding styles don't display)!

I just created a new issue for this, #1997630: RTL stylesheets not recognized for vertical tabs
Should we proceed on this or wait. The RTL css should be fine once it is recognized.

Another patch -
Removes the 2 images used in D7's vertical tabs css.
Corrects declaration ordering to comply with new CSS formatting guidelines

Sorry for another patch, but since I finally had the time to learn git rm, I wanted to get that in. There are no changes to the css, just declaration order.

This could wait until #1997630: RTL stylesheets not recognized for vertical tabs is figured out, or proceed separately.

Yep, this patch should go on regardless of #1997630: RTL stylesheets not recognized for vertical tabs, since that's a pre-existing bug in HEAD.

Thanks for the review! Status needs to be changed to RTBC :-)

Committed to 8.x. Thanks.

Oh geez, somehow I missed that this issue got created! Thanks everyone!

Updated issue summary.