Material-design-lite: support nested tabs

Created on 22 Jul 2015  Â·  22Comments  Â·  Source: google/material-design-lite

when i create a tabbar in a tab panel, selecting an inner tab closes the outer one.

to fix this, all .mdl_tabs elements should be excluded from the querySelectorAll call in tabs.js.

var allTabs = this.element_.querySelectorAll('.' + this.CssClasses_.TAB_CLASS);
var excludedTabs = new Set(this.element_.querySelectorAll('.mdl-tabs .' + this.CssClasses_.TAB_CLASS));
this.tabs_ = Array.filter.call(allTabs, function(tab) { !excludedTabs.has(tab) })

or

var noSub = ':not(' + unique(this.element_) + ' .mdl-tabs *)';
this.tabs_ = this.element_.querySelectorAll('.' + this.CssClasses_.TAB_CLASS + noSub);
MD Guidance Needed P1

All 22 comments

I don’t think nested tabs are something the MD spec accounts for. They are widely considered bad UX (as are any kind of nesting state). Closing this for now.

i have an installation guide.

i use in-content tabs to allow the user to choose his/her setup.

the first choice is binary/source/development install. if the user chooses source installation, after a common prelude he’s presented with an OS choice which will show him install instructions for a certain dependency.

what else should i use here? if it’s bad UX, you’ll have to prove how to do it better :wink:

We don't need to prove anything. StackOverflow should be able to help finding a better UX. This issue tracker is not here for support.

did the winking smiley not arrive on your side?

would you accept a PR fixing this? it’s really not hard and as mentioned i have a valid use case here.

We won't accept a PR for something we believe induces bad UX. You are free to maintain your own implementation and use that instead if you feel it is vital.

could you point me to an explaination why it is “widely considered bad UX”?

saying so does’t make it so

There is no golden rule for tabs within tabs. There _is_ use-cases where they are actually valid (but they need to be carefully crafted), however they are mostly abused where this leads to horrible UIs.

In any case, the argument here is: The MD spec doesn’t provide any guidance for nested tabs (and I don’t think I have ever seen any in a Google app – feel to prove me wrong here).

This is a part of where the opinionated part of MDL comes into play as well. We need to make decisions so sites using the project are as consistent in functionality as they can be while still expressing their unique style.

We have the opinion that nested tabs are generally bad. You believe you have a use-case where they are exceptionally useful. That's fine. We are deciding to not support this in core. Nothing is stopping you from maintaining your own JS code that allows for this. MDL was constructed very well to allow for this.

http://www.getmdl.io/ has nested tabs: the toplevel tabs and the layout/tabs examples.

the toplevel ones are simply implemented as link, but if they wouldn’t, they’d be subject to the same bug.

Ugh, why do people keep calling those tabs. That is a standard navigation menu.

because they use the same design as tabs, and have the same purpose (replacing the whole page content except from the header)

there’s no difference between mdl-layout__tab-bar and mdl-navigation other than implementation: one is mapped to a URL /directory and the other to the #fragment, one has only one page/tab loaded in the document, the other all pages/tabs that can be switched.

with a proper implementation, you could even make a tabbar load the tab via XMLHTTPRequest and update the URL via pushState, which would completely remove any difference.

but that’s beside the point. nested state is what you do as well:

http://www.getmdl.io/components#layout-section

you just chose to represent the second layer as sidebar instead of tabs.

i have it like this right now:

easy1

it may be not the best UX, but using sidebar vs tabs strikes me as a aesthetic choice

I’ll bring this up with the MD team to get their input on this.

Where in that page do we nest tabs? Other than the _examples_ to show how the components should look.

I’ll bring this up with the MD team to get their input on this.

great, thanks!


all in all i’d be happy to have some other form of hierarchical document, where you can switch out parts to get to the ones relevant to you.

  1. everyone installs the requirements: bla bla
  2. do you want to

    1. install binary? do this: bla

    2. install from source:



      1. Do this if you have windows: bla


      2. Do this if you have osx: bla


      3. ...



    3. install dev version? do this: bla

  3. now start via …

i simply don’t want to present users with the irrelevant parts.


and this is basically what navigation is for as well: allow to switch to the relevant part. no difference from tabs. so i don’t get the artificial division into “one layer of navigation” → “one layer of tabs”

Apparently, I overlooked it, but the MD spec actually says that nested tabs are a no-go.

For multiple levels of navigation, see this section.

thanks, that section is very helpful!

thanks, but i already have a working solution. also sadly yours doesn’t work. selecting a second-level tab deselects first-level tabs

Here is a working example:

https://jsfiddle.net/j44mm43k/

I know this thread is old, but I just wanted to add an observation. Sure the guidelines say nested tabs are bad, but since MDL doesn't offer an alternative, I'm forced to use tabs as the bottom navigation bar, which is a valid component according to the guidelines (https://material.io/guidelines/components/bottom-navigation.html). So from a UI perspective there are no nested tabs in my app.

As some people pointed out, there are valid use cases out there for nested tabs. In the end the user is responsible for correctly implementing material design. It seems to me the creators of the MDL framework are not.

So +1 for me. :)

@PeterWolter thank you!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

traviskaufman picture traviskaufman  Â·  5Comments

tleunen picture tleunen  Â·  5Comments

baldram picture baldram  Â·  4Comments

dryror picture dryror  Â·  5Comments

adiramardiani picture adiramardiani  Â·  4Comments