[Feature Request]: restore href functionality to Tabs

[theetrain]

The problem

I'm building a dashboard almost entirely like GitHub and some pages and layouts utilize tabs. Much like the tab representation used in a GitHub pull request—where one tab leads to a conversation and another leads to file diffs—I want to achieve the same linking functionality with server-side rendering.

With the current state of Carbon Tabs, it's encouraged to have tabs be loaded once, and use client-side navigation to toggle between content. Some disadvantages this brings are:

1. In a progressive-enhanced environment where JS is disabled or hydration fails, the Tabs will not be navigable.
2. In the scenario where one tab's contents load quickly (such as pull request comments), and the other takes a few seconds to load (such as pull request file diffs), the entire page would have to load all contents up front since anchor navigation isn't an option.

The solution

A couple of potential solutions:

1. Either a tab-like navigation component that allows href to be used, and give the active page special visual treatment
2. Restore the href prop, but encourage consumers of Tabs to maintain visual treatment when navigating between tabs and to never have a tab link to an external page with different visual treatment

Either would support the progressive-enhanced (i.e. server-side rendered page) scenario described in the problem above.

Related: #1892

Examples

No response

Application/PAL

No response

Business priority

Low Priority = release date is not dependent on fix or not upcoming

Available extra resources

I can contribute PRs for React and Svelte

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[sstrubberg]

hey, @theetrain, apologies for the lack of response here. You make a compelling case here for an enhancement to the Tabs component. In order to take this on, we would need to determine how/if we could make these navigational semantically and also patch any accessibility concerns. It may also impact any navigational patterns we recommend or suggest. Like how/if this could interact with UIShell, or not. Keeping this in our icebox for now.

[lee-chase]

@sstrubberg in my experience Tabs are used as second level navigation with either a URL or by listening for the clicks on the tabs. Very much like the Carbon website pages e.g. https://carbondesignsystem.com/components/content-switcher/usage/ switch between the URL for usage, style, code and accessibility. This includes not using cursor keys to navigate.

The current Tabs implementation behaves very much how I would expect the ContentSwitcher component to work.

Not only is the styling off for the Tabs component if you try to use an <a /> tag it also causes navigation and loss of focus as a result .

NOTE: The documentation does say "Do not use as navigation" despite the Carbon website usage of a similar UI. This has not stopped designers using it as such.

It is my belief we should make an effort to discover how design and development are using Tabs. At this point in can be argued that Carbon does not support in page second level navigation.

[lee-chase]

@guidari ^^^

[dkaushik95]

I agree. A lot of use cases that we have on a lot of products is to have a disconnected version of tabs to page. In such that the tabs are not connected to the page its viewing. In theory they are, but during implementation, we use libraries like react router which makes it hard to implement the tabs the way it is mentioned in the docs.

To overcome the accessibility issues, I have seen some products use an empty div and put the attribute id so that it meets the checks.

Currently we are implementing a version of TabNavigation on our product which uses the same classes and styles as a tab and it meets our accessibility and functional requirements. We would love to have this component coming directly from carbon so it remains consistent with the rest of our products.

Here's the accessibility checker and the html output of the component.