Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Issue tags: +mobile

This sounds like an issue for the new mobile initiative to me.

drupalninja99’s picture

It seems to me that vertical tabs maybe should auto-disable when the width is too small. It would be better I think to have the dropdown fieldsets you have without vertical tabs on mobile deveices.

kika’s picture

FileSize
80.41 KB

I propose to change vertical tabs into accordion when viewport is narrow. See the mockup below.

Also, there are similar patterns in the air in "Redesigning the Create Content page" discussion http://groups.drupal.org/node/214898, especially in the mockup http://groups.drupal.org/files/Sidebar-mockup-seven.png and http://groups.drupal.org/files/create-content-mobile.jpg but note that even after redesign create content page we have vertical tabs all over the admin interface so it needs a generic responsive solution.

kika’s picture

Title: Vertical tabs take up too much horizontal space on smaller screens » Responsive vertical tabs
Issue tags: +UI pattern

Hijacking the title, sorry.

moshe weitzman’s picture

Accordion looks quite sensible to me.

droplet’s picture

EDIT: Should we redesign it. or use exist collapse.js pattern ?

(forgot it will show tabs summary)

headdragon’s picture

Looks good.

nod_’s picture

Issue tags: +JavaScript

just tagging to keep on my radar.

LewisNyman’s picture

Status: Active » Needs review
FileSize
12.1 KB

Heads up. Got a patch!

Simple conditional checking the width of the viewport. The patch looks massive because I've added code indentation but it's really just two lines for the if statement.

droplet’s picture

Status: Needs review » Needs work
Issue tags: +Needs design review
+++ b/core/misc/vertical-tabs.jsundefined
@@ -11,185 +11,191 @@
+if (document.documentElement.clientWidth > 640) {

Didn't test but I think it needs to be configurable. and resize handler ?

quartsize’s picture

Here's a very rough proof-of-concept of #3 in Stark. I would have preferred to have only one set of tab buttons, but I wasn't finding a way to make an accordion out of the non-interleaved setup, or vertical tabs out of the interleaved setup, so in addition to the li-tags, it adds h3-tags with the same contents between the fieldsets, and uses a media-query to display one set or the other.

dcmouyard’s picture

I agree with droplet that the patch in #9 this needs a resize handler. Making the width configurable would also be nice.

For #11, switching to an accordion view on small screens isn't necessary because the fieldsets can still be collapsible.

LewisNyman’s picture

A resize handler? Do you guys really want to UI to dramatically change when the user resizes the window or changes orientation?

That sounds detrimental to UX rather than an positive addition.

Bear in mind this is a stopgap fix and once we are able to we won't even load the vertical tabs code unless needed.

aloyr’s picture

to add a bit to #13, do we really need configurable breakpoints for resizing? those are mostly driven by convention, no?

dcmouyard’s picture

The reason I would like to use the resize handler is for accessibility. If somebody zooms a page enough, then the vertical tabs become very difficult to work with. Having it switch to collapsible fields is definitely preferred.

Having a configurable breakpoint would be nice because different designs use different breakpoints.

Bojhan’s picture

@dcmouyard I am not sure I am in agreement here, you are voicing for a very complex design both technically and UX - that is non-standard in core.. People do not want other interfaces, when you zoom - its a very common opinion from our accessibility team not to make special interfaces.

dcmouyard’s picture

Issue tags: +Accessibility

We definitely need to consider people with low-vision who zoom pages when dealing with UI patterns. Fortunately, it's usually an easy fix to cater to this group, especially using responsive design techniques.

Jeff Burnz’s picture

It would be good if someone could explain exactly what would happen with this resize handler - give some examples of how this would be used in real life. It seems to me having a UI change on orientation change is a no go, not friendly and something to avoid. What about users with really big screens, lets say 27" and is zoomed right in, what happens then? What are we testing for here - window width or document width? What happens when the document width is wider than the window width (aka horizontal scroll/keyhole viewing)?

The problem with "vertical tabs zoomed right in" stems from setting the width of the tabs list in ems, so when zoomed it gets really wide, if this were in pixels, say using media queries, then it would by and large eliminate the issue, afaikt. Just thinking that it might make more sense to fix vertical tabs in some way, rather than changing the UI.

droplet’s picture

JS side, technically is not complex. I think that more parts in CORE will be in the same way. width 640px and width 1200px are different styles. eg. Toolbar, Menu.

Vertical Tabs are the menu too.

Resize handler is equal to "@media (min-width: xxx)" in stylesheet. This is responsive design.

use case:
I opened a webpage at 800px but the design width is 1200px, then I do a resize to my browsers. I would like to see the standard vertical tabs.

and not all elements view at first glance. eg. vertical tabs at veryyyyy bottom of the page, "resize, different style,...etc XYZ" It do not affect any UX problem.

This is very common *responsive* web patterns.

LewisNyman’s picture

#17
Do you mean setting the breakpoint in ems? That makes sense

nod_’s picture

Perfect use-case that'll help me get rid of Drupal.behaviors, thanks :)

dcmouyard’s picture

Let's take a look at the node/add page to see this in action.

If vertical tabs is disabled, we just see collapsible fieldsets.

vertical tabs disabled

When it's enabled, we see vertical tabs.

vertical tabs enabled

Using the patch in #9, we see collapsible fieldsets unless the screen width is greater than 640px, at which point we see vertical tabs.

collapsible fieldsets at small screen widths

This patch, however, only checks the screen width when the page loads. If we change the screen width to 640px or less then we still see the vertical tabs and not the preferred collapsible fieldsets.

There are three main ways to change the screen width:

  1. Manually re-size the browser window. Usually only people familiar with responsive design do this, so it's not a major concern.

  2. Changing the orientation of certain devices. As Jeff Burnz mentioned, changing the UI on orientation change isn't good practice. If the UI becomes unusable on orientation change, however, then changing the UI is beneficial.

  3. Changing the zoom level on non webkit browsers. This is the main use case for people with low vision.

  4. So if you load the page then zoom in, we still see vertical tabs.

    vertical tabs when zoomed in

    Ideally, we want a resize handler to trigger vertical tabs on or off at the specified breakpoint. So if we do zoom in enough, we'll see collapsible fieldsets.

    collapsible fieldsets when zoomed in

Jeff Burnz’s picture

Why do I want to see collapsible fieldsets just because I zoom in on the page?

How will we know content is not visible (off screen in some direction), and moreover, that this is not what the user wants?

dcmouyard - you said:

Ideally, we want a resize handler to trigger vertical tabs on or off at the specified breakpoint.

What breakpoint? How will we know what is the "right breakpoint". What will this magical number be and how is it arrived at?

dcmouyard’s picture

Why do I want to see collapsible fieldsets just because I zoom in on the page?

For the same reason you want to see collapsible fieldsets instead of vertical tabs on a mobile device with a narrow screen. Read the initial issue summary.

How will we know content is not visible (off screen in some direction), and moreover, that this is not what the user wants?

Responsive themes adjust the layout to fit the screen. I'm pretty sure most users dislike horizontal scrolling.

What breakpoint? How will we know what is the "right breakpoint". What will this magical number be and how is it arrived at?

That's why I would prefer to have the breakpoint be configurable instead of hard-coded. Whatever breakpoint we decide upon for small screens will also work for users that zoom.

Jeff Burnz’s picture

Providing a setting for a configurable breakpoint is not really a winning solution. First, discover-ability, where to put it, how to educate low skilled users to use it etc etc, its a can of worms. Lets not fall back on ye old "add another setting". I would much prefer to see us concentrate on making vertical tabs work rather than adding more UI cruft.

Remember, we only need to support 200% zoom for most users, we can't hope to support every edge case and should refrain from trying to do so. Also the main issue with VT is CSS, with of the tabs list set in ems, I know this is fixable with a little CSS in media queries.

And lets never fall back on collapsible fieldsets, the accordion pattern is nice, will leave that to our venerable UX team to deem worthy. Perhaps that (accordion) is a longer term type goal.

dcmouyard’s picture

The fallback is simply not using vertical tabs. On the node/add page it's currently collapsible fieldsets, but in other cases it might be regular fieldsets.

Just setting the tabs list width in ems will not fix the issue. There might be a CSS fix using media queries, which @quartsize started working on in #11. If we're using JS to trigger vertical tabs, though, then we should to use a resize handler.

Here's some pseudo code for how a resize handler could work:

var breakpoint = '640';

// Use matchMedia if supported.
if (matchMedia) {
  // Set media query to trigger vertical tabs.
  var mq = window.matchMedia('(min-width: ' . breakpoint . 'px)');
  // Add event listener to test media query when the window is resized.
  mq.addListener(WidthChange);
  // Call function on page load, otherwise it will only trigger on resize.
  WidthChange(mq);
}
// Just test breakpoint on page load in older browsers.
else if (document.documentElement.clientWidth >= breakpoint) {
  VerticalTabs();
}

function WidthChange(mq) {
  // Use vertical tabs when the media query matches.
  if (mq.matches) {
    VerticalTabs();
  }
}

function VerticalTabs(){
  // Vertical tabs code goes here.
}

I think the main question now is whether we want to focus on a CSS media query solution to changing how vertical tabs work or use JS to turn on/off vertical tabs at some breakpoint. Using a JS-only solution would be easier to implement, but a CSS solution would probably have better performance.

droplet’s picture

Configurable is winning solution for both low skilled and adv users. Use Drupal.settings to trigger On/Off.

CSS side, no changes.
JS side, you have more options now = turn on / off for special case

Will D8 load separated media stylesheets for mobile devices?? D8 supports IE8, there is no matchMedia supports. Use the same fallback lib :)

matchMedia(xxxxxxx) 

==

// browser viewport
documentElement.clientWidth

// or
$(window).width(); 

only slightly performance impact on JS matching.

the exist lib we have vTab ON handler, so add a new vTab Off to it:

vTabs on = adding css classes and a UI tag for menu

vTabs off = remove vTabs css classes (show old collapsible fieldsets) and hide menu.

I bet @nod_ has more idea on configurable JS Lib in CORE. (the drupal way)

Changing the zoom level on non webkit browsers. This is the main use case for people with low vision.

on mobile / tablet ?

LewisNyman’s picture

We don't need to use matchMedia to check the width of the viewport. Browsers have been able to check the width of elements for years. My original patch at #9 is checking the width of the root element. I don't see the benefit of using match media.

dcmouyard’s picture

@lewisnyman - What I like about using matchMedia is that it's easy to add an event listener for when it changes. When adding an event listener for onresize. you need to set a time limit on how often you check it, otherwise browsers that continuously check it will overload and crash. I know we're only supporting IE8+, but we still don't want to shouldn't crash their browser.

My psuedo code falls back on documentElement.clientWidth for browsers that don't support matchMedia.

@droplet - Even on mobile/tablet devices. On webkit browsers page zooming doesn't trigger media queries because they want the keyhole effect, because it's easy to scroll on a touch device. I think they need to separate the traditional page zoom event from the touch pinch-zoom event. You want the former to trigger media queries, but not the latter.

Back to the main question though, should we focus on a CSS media query solution, or a JS-only solution?

dodorama’s picture

Back to the main question though, should we focus on a CSS media query solution, or a JS-only solution?

Is there any issue or discussion open on a global strategy on how to do responsive design in d8 (javascript or CSS) ?

nod_’s picture

After thinking about it I'd go with the breakpoint. matchMedia would be ideal but has poor browser support: http://caniuse.com/#feat=matchmedia and I don't know how well the polyfill works: https://github.com/paulirish/matchMedia.js/

For discoverability, I say just put a data-breakpoint attribute on the wrapper element and make that a standard across core. If you need to change the value, we need a js wrapper that will fire an event to allow script to recalculate things with the new value. It's easy, it's clean and discoverable. How do you like this sideways solution?

LewisNyman’s picture

I don't see anybody asking whether we should use just JS or CSS but I think the answer here is it depends on what we are trying to adapt.

I don't see the benefit in a blanket "we are only going to only use JS or CSS" rule. Different tools are better for each situation.

It so happens for vertical tabs that disabling the vertical tabs JS gives you an accordion which is perfect for what we want on small screen devices. Hopefully in the future we won't load the file at all.

droplet’s picture

Does dcmouyard means use PURE CSS ? only use matchMedia polyfill (JS) to non-supported browsers.

I bring out a new issue, vTabs should be less JS depends: #1503072: Always show vertical tabs button(menu) links

and this one: #1502986: make vertical tab buttons support left/right/top/bottom placement
(if only 3 links, someone may like to show tab menu on the top instead other solutions)

dcmouyard’s picture

For my CSS versus JS question, I was only referring to vertical tabs. As @lewisnyman mentioned, which method we use should be decided on a case-by-case basis.

Here are two approaches we can take to make vertical tabs work at small screen widths:

  1. Set a breakpoint in vertical-tabs.js so that vertical tabs won't render below that breakpoint.
  2. Change the markup and CSS of vertical tabs so that it works, regardless of screen width.

#1 is easier to implement and would have better performance for mobile devices if we can use a script loader. I'll still argue for a resize handler if we go this route though… :-P

#2 is probably a better all-around solution, and we might be able to combine this solution with #1502986: make vertical tab buttons support left/right/top/bottom placement.

dodorama’s picture

I think it's worth looking at the discussion going on here about the create content screen cause it could make the vertical tabs pattern somehow obsolete. That would mean keeping collapsible fieldset or an accordion both for mobile and desktop.

yoroy’s picture

Vertical tabs are used in other places in core as well, so not necessarily obsolete anytime soon.

Lets try and make some explicit decisions regarding breakpoints. Make them overridable, sure, but making them configurable (in the UI?) puts the burden on the user to make a decision. We should try and provide sensible defaults here.

It's hard to tell for me how much code complexity the resize handler would add vs. the gains we'd get from it. Again, I hope we'll get to a sensible and balanced resolution.

(I see many js-related issues that refer to some kind of script loader. #1033392: Script loader support in core (LABjs etc.) if you didn't know already :-)

mgifford’s picture

You're probably going to use something like this:
patch -p0 < path/file.patch

But there are instructions here for how to do it from Git:
http://drupal.org/node/707484

quartsize’s picture

A reworking of #11 to use the legends for the inner tabs instead of h3s. Still very incomplete.

yoroy’s picture

Status: Needs work » Needs review

Triggering testbot

quartsize’s picture

Here's more, still only for Stark (for which I think the styles should be finalized before editing Seven and Bartik to match).

Does this look like a worthwhile approach?

RobLoach’s picture

Status: Needs review » Needs work
Issue tags: +JavaScript, +Needs design review, +mobile, +Accessibility, +UI pattern

The last submitted patch, responsive-vertical-tabs-1277352-40.patch, failed testing.

quartsize’s picture

gmclelland’s picture

How about using this technique to detect the media query and respond accordingly?
http://www.springload.co.nz/love-the-web/responsive-javascript
https://github.com/JoshBarr/js-media-queries

I also started another issue for being able to detect the active media query #1621594: Media Query Detection

leenwebb’s picture

If vert tabs are transformed into accordions, please be sure to do screen reader testing and keyboard-only testing; some of the obvious solutions that work well with one of those technologies are problematic in the other.

(via Montreal Accessibility Sprint)

RobLoach’s picture

FileSize
35.34 KB

Out of pure curiosity, I tried switching the vertical tabs completely with jQuery UI Accordion. Not sure how I feel about the result, although it is a lot less code.

Drupal.behaviors.verticalTabs = {
  attach: function (context) {
    $(context).find('.vertical-tabs-panes').once('vertical-tabs', function () {
      $(this).accordion({
        header: 'fieldset legend',
        autoHeight: false
      });
    });
  }
};
nod_’s picture

I'm really not in favor of putting jquery UI all over the place. This stuff will delay page load by at least 0.5s on mobile we need to chose performance or jQuery UI.

RobLoach’s picture

Agreed! I wasn't really happy with it either.

LewisNyman’s picture

Status: Needs work » Needs review

The latest patch doesn't apply.

Status: Needs review » Needs work

The last submitted patch, responsive-vertical-tabs-1277352-43.patch, failed testing.

quartsize’s picture

Updated patch. Again, rough proof-of-concept, only styled for Stark.

quartsize’s picture

Status: Needs work » Needs review

"Needs review" for testbot.

moshe weitzman’s picture

Would be good to post screenshot of latest patch, and update Issue Summary.

Bojhan’s picture

nod_’s picture

Implemented solution outlined in #22. If screen is too small we don't execute vertical tabs and fall back to the default collapsed fieldsets. We're already using this pattern to kill the overlay on small screens. Once we know more about what we'll support for media queries and all we can improve the detection. Fow now it's a low-tech solution that works and works fast.

#51 is pretty nice in stark but it's pretty complicated for a result very much similar to what not using vtabs is like. What I'm asking is how much benefit we get from making a sort of responsive vertical tab when a 3 line patch can take care of the issue? Not trying to undermine the current patch, just wondering if a more simple and direct solution could work.

For screens of what it looks like, refer to #1277352-22: Responsive vertical tabs.

JohnAlbin’s picture

I really like the idea of vertical tabs converting to accordions on small screens… scratch that.

I really like the idea of accordions converting to vertical tabs on larger screens.

How about we commit the patch in #55 (which I just tested and seems to work fine) and then look into if its feasible for accordions to convert to vertical tabs. (I agree with earlier assessments that using jQuery UI for that is a no-go for mobile devices.)

Semantically, these things are fieldsets. So my first thought of writing them as details/summary HTML5 elements doesn’t make sense. (There's also accessibility problems with those elements. See http://html5doctor.com/the-details-and-summary-elements/ )

Actually, the only real difference I see between a list of collapsible fieldsets and a list of details/summary elements is the margin between the fieldsets. Hmm…

What if we removed the margin between collapsible fieldsets in the Seven theme? By adding this CSS after line 546 in core/themes/seven/styles.css:

.collapsible + .collapsible {
  margin-top: -1em;
  border-top: none;
}

Huh. Actually, this is starting to look a lot like kika’s “original proposal” design in comment #3.

I've updated Nod's patch to add some CSS to get it closer to that design. Am I crazy to think we can just use our normal collapsible fieldset JS with some CSS to make it look and act like an accordion?

Bojhan’s picture

Issue tags: -Needs screenshots

What is the height of these rows in pixels? As I am concerned about the size of hit targets, other than that this seems fine - I am wondering if it has any side effects though or only really occur on your mobile phone.

quartsize’s picture

If I remember correctly (it's been awhile), the reason my patch has been so complicated is that I wanted the interface to be able to potentially take advantage of the space afforded by an orientation-change (and switch back, if the space goes away). Correct if wrong, but it looks like nod_'s patch achieves its simplicity by not doing that. Maybe the orientation-change support isn't worthwhile, but I figured I'd at least explain my monster.

JohnAlbin’s picture

@quartsize: Hey, thanks for all your work! I thought until yesterday that we needed a monster to get this working. :-)

quartsize’s picture

So I've thought/recalled more. I suspect some sort of monster is necessary if one wants the orientation-change thing. The five line solution in attach() completely disables vertical tabs until another page load, so you'll just have wider collapsible fieldsets when you change orientation. And I'm not sure they should be styled like vertical tabs, because they don't have the one-tab-at-time nature of tabsets and accordions.

So suppose you trap the orientation change / window resize event, and run vertical-tabs if there's enough space. You'd need code to reverse the effect if the dimensions change again, hiding the markup vertical-tabs.js must generate to make the document flow correctly, synchronizing the summaries, and uncollapsing the fieldset of the open tab while collapsing the others. I think that's the monster right there, the difference being that #51 tries to keep everything in sync before dimensions change, so it can be handled faster in CSS. The complexity isn't really in doing one or the other (accordion or vertical-tabs); it's in being able to switch between them without reloading the page.

And actually, I've been talking about orientation changes / window resizes that increase width. What happens with #56 if width decreases through the breakpoint?

So I think it boils down to: how do we want to handle dimension-changes (if at all -- I'm reading nod_ as saying it didn't bother the folks working on the overlay)?

nod_’s picture

The main issue here is to have a working patch with the basic behavior in before feature freeze. Then it's just a matter of improving the already-in feature up until April.

The overlay thing isn't a great solution but the fact is that is unbreaks navigation on mobile (overlay just doesn't work on mobile). The orientation change and all should be taken care of globally, not just for this or the overlay. So until we get a proper and good enough way of doing that, we should keep it simple and make sure the experience is decent on mobile :)

quartsize’s picture

"We don't have the time right now for such a solution, so just rely on page-refreshing" is certainly a possible answer for how to handle dimension-changes. If that's the route we're going, I'd favor #55 without the CSS changes, for my aforementioned reason (unless we're going to make the behavior analogous, but then we're complicating things again).

nod_’s picture

+1 about the comments on styling and behaving as an accordion in #60

@quartsize, I personally don't have time for it but if you'd like to come up with a more generic way on how to handle that in a new issue, please do :) I'd be happy to help you with what I can.

Bojhan’s picture

Status: Needs review » Reviewed & tested by the community

I am going to RTBC #55 , although we could go for better styling as sugessted in #56 - that has several issues and optimization (e.g. increasing the click area) that could we do post freeze. Let's first get this bug out of the way.

webchick’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Ok, looks nod_, JohnAlbin, quartsize, and Bojhan are on agreement about the principles of #55, so committed and pushed #55 to 8.x.

But now I'm a little confused about what to do with this issue. it doesn't feel like it's really "fixed." At minimum, I think we need a follow-up for that "generic portrait to landscape orientation handling" behaviour. Looks like we also might want to make another issue (as a "normal task") to discuss further style changes that's not already at 60+ replies?

Marking postponed (needs more info) as a result. :)

nod_’s picture

Status: Postponed (maintainer needs more info) » Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.

zmove’s picture

Is there any 7.x backport of this planned ?

nod_’s picture

Nope.

magnetive’s picture

Issue summary: View changes

This not a Accordion Solution but for me, it's OK.
I made it only with CSS:

@media all and (max-width: 480px)
{
div.vertical-tabs .vertical-tabs-panes
{
	margin: 0px 0px 0px 0px !important;
	padding: 0px !important;
	display: block !important;
	width: 100% !important;
	float: none !important;
	max-width: none !important;	
}
	
div.vertical-tabs .vertical-tabs-list
{
	width: auto !important;
	margin: 0px;
	border: none !important;
	display: block !important;
	float: none !important;
}
	
div.vertical-tabs ul.vertical-tabs-list li
{
	border-left: none !important;
	border-right: none !important;
}
	
div.vertical-tabs-panes fieldset
{
	width: 100% !important;
	max-width: none !important;
}
	
div.vertical-tabs-panes .fieldset-wrapper
{
	max-width: none !important;
	width: 100% !important;
}
	
div.vertical-tabs
{
	margin: 0px;
	background: none !important;
}
}
deanflory’s picture

+1 for a D7 backport or contrib module. Please! Pretty please!

EDIT: Trying this sandbox now for D7:
https://drupal.org/sandbox/tkoleary/2236189

anil_89’s picture

I have used this css working fine for responsive tab. thank you for support.....

rcodina’s picture

I know this is not exactly a backport but if anyone is interested in having responsive vertical tabs on drupal 7 just check out Vertical Tabs Responsive module:

https://www.drupal.org/project/vertical_tabs_responsive

quicksketch’s picture

Status: Closed (fixed) » Active

But now I'm a little confused about what to do with this issue. it doesn't feel like it's really "fixed."

As an alternative to a generic solution (which looks like it's been postponed to 9.x in #1812298: Handle mobile orientation change for JS widgets), over in Backdrop-land @wesruv figured out how to accomplish this with no significantly different JS and just a media query: https://github.com/backdrop/backdrop-issues/issues/515. It does require restructuring the markup a bit however. But overall, it's a great solution that is truly responsive and is simple in its implementation.

I'm going to move this back to "active" if we wanted to pursue further improvement in D8.

wesruv’s picture

I wouldn't say 'necessary', so much as 'preferable'. I only added classes to HTML for nicer styles. Didn't end up changing markup.

Mobile is an accordion pattern with the legend as a toggle. This means the legend also gets a summary (so there are two summaries to update).

The desktop styles are more or less the same as 7 core, but with the added bonus of having max width on inputs actually apply in WebKit, Blink and Firefox.

Fieldsets and tables don't behave well with children that have max width... Because stupid reasons that are in the W3C spec :(

Documented all that in the Backdrop commit and accompanying video demo.

wesruv’s picture

My solution probably needs to be postponed to 8.1.x per this: https://www.drupal.org/core/d8-allowed-changes#evaluate

But I'm going to try to make a patch this weekend, see if I can get it to work. I will postpone this after the patch goes in, because apparently the the tests I want to run for this patch should be on 8.0.x... or something.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • webchick committed 546fcdf on 8.3.x
    Issue #1277352 by quartsize, lewisnyman, nod_, JohnAlbin, kika,...

  • webchick committed 546fcdf on 8.3.x
    Issue #1277352 by quartsize, lewisnyman, nod_, JohnAlbin, kika,...

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • webchick committed 546fcdf on 8.4.x
    Issue #1277352 by quartsize, lewisnyman, nod_, JohnAlbin, kika,...

  • webchick committed 546fcdf on 8.4.x
    Issue #1277352 by quartsize, lewisnyman, nod_, JohnAlbin, kika,...
jibran’s picture

Status: Active » Fixed

@quicksketch and @wesruv please open up a follow-up issue with the correct version.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

deanflory’s picture

Any chance of a D7 version?

nod_’s picture

Not in core, and even then, it's not a real responsive solution.

edurenye’s picture

We should make that configurable, say you change the style of the tabs to have the text vertically and the tabs with less width, then you might not have this problem, but then in mobile with that fix everything is broken.

edurenye’s picture

I created this issue #2971840: Make responsiveness for vertical tabs configurable to fix the problem stated in the previous comment.

andrewmacpherson’s picture

cleaning up the a11y maintainer queue