Fluentui: Pivot: Support overflowing pivots

Created on 22 Feb 2018  路  33Comments  路  Source: microsoft/fluentui

Hi all,

I think this would be nice. Do we have any plan to handle Pivots are overflowed.?

Thank in advance,
Quang Le

Pivot Backlog review Design 馃帹 ASAP Fixed Feature WCAG 2.1 help wanted

Most helpful comment

Yes @shaipetel is correct. We should leverage the common Fabric pattern of the overflow. Here鈥檚 the states:
image

and examples:
image

Pretty simple. If a pivot in the overflow is selected, then the selection visual should be used.

All 33 comments

@betrue-final-final is this something we have a design for, or something we want to support? If there is a different pattern we should be following instead, that's fine too.

Consider refactoring pivot using base of pagination control. At that point supporting overflowing of pivot items. #7254

I believe the expected behavior would be for Pivots to scroll horizontally once they've exceeded their container's width. That's the pattern I've seen most frequently for this kind of behavior. @betrue-final-final , would be curious to hear if you have different thoughts.

Same here, there isn't even a trigger we could handle the overflow ourselves.
A good solution would be either to scroll the tabs horizontally, or to automatically collapse the over-flowed items into a "..." more drop down menu, when the page is resized and there is not enough room to render fully.

Anyone has a solution for this?

For now, I'm doing it manually but adding a style to the pivot element:

Works, but doesn't look great...

Just putting it out there in case anyone needs it.

Another way i found was to give them a specific width, and make the text in the tab trncated with ...

using (for example with 4 tabs):
<Pivot styles={{ linkIsSelected: { width: '25%' }, link: { width: '25%' }, text: { overflow: 'hidden', textOverflow: 'ellipsis', width: '100%' } }}>

and override the PivotItem render item link:
onRenderItemLink={(link, defaultRenderer) => { return (<div style={{ width: '100%' }}> {defaultRenderer!(link)} </div>); }}

Just as a design note: Pivots should never stack like that. It might 'solve' the overflow issue but it creates other problems and isn't an approved design. We should solve this holistically and thoughtfully within the component before we have multiple teams and products doing various different things here. I think ideally, all the places we have Pivots (UWP, Web, etc) align.

Agreed. It's also worth mentioning that a fixed width will not work for a couple of reasons:

  • The current pivot indicator should be the width of the string
  • Will have inconsistent spacing between pivot items with long and short string lengths
  • Localization will be problematic

Of course, a proper solution is much needed here, in the form of an overflow menu (...), or any other clever solution you come up with.

Since in my design I do not know the number or names of tabs I cannot hard code something like that with reasonable effort, I鈥檓 ok with my patches for now.

I need Pivot to be rendered as vertical tabs with more than 9 tabs. Any suggestions ?

Yes @shaipetel is correct. We should leverage the common Fabric pattern of the overflow. Here鈥檚 the states:
image

and examples:
image

Pretty simple. If a pivot in the overflow is selected, then the selection visual should be used.

Hey @micahgodbolt can we kick this up again?

Yeah, this is certainly doable. Treat the top of the pivots like a command bar. It might require a decent bit of refactoring, but it's a good direction forward.

Just wondering whether there is any plan to implement this in the roadmap? We are looking for the same kind of functionality.

Yah we should get on this sooner than later. We need it for WCAG 2.1 compliance.

adding resizeGroup to this control would make it reasonably easy to achieve this, but it would also cause some issues for any pivot rendered in a flexible container

i.e. if the pivot parent only grows to be as big as the pivot, the resizable pivot will think it ran out of space and not try to grow.

For this reason, it's important that we make this change as an opt in prop for now.

I'm ok with opt. Could we expose a prop of type ComponentType that renders as the wrapper? This way if someone wants some other component logic or behavior it's possible?

we can expose the resizeGroup props and allow people to change the logic of the resizing for sure. We already do that on command bar. If you want to remove icons first, then see if it fits, you can do that before pushing items into the overflow.

we can expose the resizeGroup props and allow people to change the logic of the resizing for sure. We already do that on command bar. If you want to remove icons first, then see if it fits, you can do that before pushing items into the overflow.

I have used the logic you have in command bar already and that works great so I would be happy to follow the same pattern here.

@micahgodbolt is there an ETA for this ?

a dev has been working on a solution, but it has been more difficult than expected to support this feature without regressing the existing control.

https://github.com/OfficeDev/office-ui-fabric-react/pull/11270

@micahgodbolt can we get an update here? We're blocked on this for many features.

@brandonthomas can you combine a pivot and resizeGroup to enable those features? I don't see a way to make this change without breaking existing users. A fully responsive pivot (that changes its default behavior) would need to be in a major release or new control

@micahgodbolt I think putting the onus on all the consumers here is going to be a hard pill for most to swallow and will make it so all apps have to do this work custom not just us. Is there anything else that can be done to support it? Can we create a ResponsivePivot component that does that so we have consistency? We feel like it's a major change and not a minor not from an API perspective but because it would move items into a context menu?

Additionally, ResizeGroup doesn't work when there are in-app width changes as it hooks into window resize. So if you have elements adjusting size within the app or panels coming in it won't catch that from what I can tell in the component.

@micahgodbolt or @xugao in order for this to work with in app resizes the only path forward I see is to basically build my own ResizeObserver based ResizeGroup and then wrap Pivot in that, and then adjust what PivotItems are shown, and if I can't fit them, toss them into an overflow. Do you see another option? This feels like a heavy lift for every team to make to get WCAG 2.1 compliant.

Could the FluentUI team provide a recommendation in CodePen while we are waiting for something to be built into the library? Without this, users are building their own reflow stories and losing not only cohesion where it's needed but also the benefit of using a shared library that otherwise has high standards for accessibility and usability.

Evaluating this right now.

An update:

  • This would be a breaking change, so we're scaffolding this in react-next, our v8 prerelease package
  • The code is being converted to function components presently and that's almost completed
  • The styles will be converted to sass and css variables to leverage our performance improvements and unified theming model.
  • The design mentioned above has some issues that we're hoping to resolve with @betrue-final-final before implementing (would prefer to use a carousel model instead of the dropdown option.)

@dzearing do we have a guestimate on when this will be available in v8? I'm ok with waiting a bit but if it's something like March next year we'll have to do something in the short to intermediate time frame to address.

The guestimate here is that it will start in June. We're closely tracking. @behowell is working on this.

Work is currently in progress.

@dzearing you said you "would prefer to use a carousel model instead of the dropdown option." but it looks like the the PR by @behowell is back to an overflow menu. I'm curious what factors made the carousel model untenable

Was this page helpful?
0 / 5 - 0 ratings