Material-ui: [Tabs] Default 'width' to 'auto' instead of '100 / n%'

Created on 25 Mar 2016  路  8Comments  路  Source: mui-org/material-ui

I propose considering that Tab components are not equal width by default. If you are putting content in the Tab elements of variable width, the tabs do not render gracefully:

In the situation below, my Tabs are in side an AppBar component.

Tabs with 'width' set to '100 / n%' (in this case, 20%):

screen shot 2016-03-25 at 11 55 50 am

Tabs with 'width' set to 'auto':

screen shot 2016-03-25 at 11 56 09 am

I'd be happy to open a PR if consensus is in favor of the change.

Tabs enhancement

Most helpful comment

Yeah I'm working on a method to calculate the position the inkbar should be in using getBoundingRect. this way, the inkbar will be positioned correctly depending on hot each Tab is rendered, not on how it assumes it will be rendered.

All 8 comments

This PR https://github.com/callemall/material-ui/pull/2861 was going into this direction. You can read it if you are interested.

I propose considering that Tab components are not equal width by default.

I think that we should have a property to enable this feature :+1: .
I'm not sure that it should be the default.

I think it'd be a sensible choice to default the width to 'auto'. It would do no harm from a backwards compatibility perspective. Anyone currently using the Tabs component with Tabs that have same width would not be impacted, as it would render identically.

@alitaheri is still working on a fork of #2861. Might be worth waiting until he's back from vacation to see whether this is already covered.

In any case, I understand what you're saying about auto by default being a non-breaking change, as min-width (I'm assuming) will make the tabs evenly spaced by default.

I'm back :grin:

auto is better in my opinion too. But it makes no sense if fillWidth is true. and same-size doesn't make sense if fillWidth is false. so i think this behavior should be controlled by that.

And Scrollable Tabs must have fillWidth set to false.

Is that ok? does that make sense?

I realized a new concern when working with tabs today.

The inkbar implementation is percentage-based. so if you create Tabs with the inkbar, but set the width of each Tab to auto, you get a visually undesirable output:

screen shot 2016-03-29 at 11 33 54 pm

In this particular case, the inkbar bleeds into the leftmost tab with width and left values of 33%. This is because the inkbar assumes equal with tabs.

I can make each tab the same width, but then the padding between each Tab becomes variable.
This can be problematic when the width of text of each tab is significantly different:

screen shot 2016-03-29 at 11 40 23 pm

Yeah I'm working on a method to calculate the position the inkbar should be in using getBoundingRect. this way, the inkbar will be positioned correctly depending on hot each Tab is rendered, not on how it assumes it will be rendered.

Any update on this?
On a desktop, I want the tabs to show up with 24px padding on either side
The spec (you'll need to scroll down to spec > desktop.

The only way to do this is to either try to calculate the width based off the text length (which is janky), or explicitly set the padding to what I want which screws up the ripple.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mattmiddlesworth picture mattmiddlesworth  路  3Comments

finaiized picture finaiized  路  3Comments

ghost picture ghost  路  3Comments

sys13 picture sys13  路  3Comments

chris-hinds picture chris-hinds  路  3Comments