feat(cdk-experimental/ui-patterns): tabs ui pattern #30568

ok7sai · 2025-02-28T18:20:13Z

No description provided.

src/cdk-experimental/tabs/tabs.ts

src/cdk-experimental/ui-patterns/tabs/tablist.ts

src/components-examples/cdk-experimental/tabs/cdk-tabs/cdk-tabs-example.css

src/cdk-experimental/ui-patterns/tabs/tablist.ts

src/cdk-experimental/tabs/tabs.ts

src/cdk-experimental/ui-patterns/tabs/tabpanel.ts

src/cdk-experimental/tabs/tabs.ts

src/cdk-experimental/ui-patterns/tabs/tablist.ts

jelbourn · 2025-03-05T00:21:54Z

src/cdk-experimental/tabs/tabs.ts

+    'class': 'cdk-tabs',
+  },
+})
+export class CdkTabs {


I'm a little unsure about having CdkTabs as a necessary wrapper / container vs. the tabpanel having a reference/input for the tablist, implying a 1:1 relationship between tablist and tabpanel.

I was going to include the decision making of choosing a top-level wrapper in the design doc for later. Here's a quick comparison.

Passing references

<ul cdkTablist> <li cdkTab #tab1="tab">tab1</li> <li cdkTab #tab2="tab">tab2</li> </ul> <div cdkTabpanel [for]="tab1"></div> <div cdkTabpanel [for]="tab2"></div>

Note that the template variable referencing can be reversed. The only dealbreaker I can think of is the dynamic generated tabs or tabpanels via control flow may be impossible. Another downside is the templating effort of creating template references for general use case.

The wrapper solution on the other hand can support both implicit and explicit(yet implemented, but likely via a string identifier other than id) tab-tabpanel binding, which I think it's more intuitive. I also found the same pattern used in most similar libraries, so it can be familiar to developers as well.

Yeah, I think we should probably have a discussion on the API(s) we expect an end-developer to define for their own tab implementations, and then how to best accommodate that with the directives. FWIW I think we will have a requirement that there may be elements between the tablist and the tabpanel(s).

For content, I suspect these directives will need to end up being oriented around rendering <ng-template> content.

src/cdk-experimental/tabs/tabs.ts

src/cdk-experimental/ui-patterns/tabs/tab.ts

jelbourn · 2025-03-05T00:34:50Z

src/cdk-experimental/ui-patterns/tabs/tab.ts

+/** The required inputs to tabs. */
+export interface TabInputs extends ListNavigationItem, ListSelectionItem, ListFocusItem {
+  tablist: Signal<TablistPattern>;
+  tabpanel: Signal<TabpanelPattern>;


It seems odd to me that the tab would need to know about the tabpanel. I was imagining the relationship would be that the tabpanel only knows about the value of the tablist, not necessarily any of the specifics tabs

src/cdk-experimental/ui-patterns/tabs/tab.ts

src/cdk-experimental/ui-patterns/tabs/tabpanel.ts

src/cdk-experimental/tabs/tabs.ts

jelbourn · 2025-03-06T23:51:23Z

src/cdk-experimental/ui-patterns/tabs/tabpanel.ts

+}
+
+/** A tabpanel associated with a tab. */
+export class TabpanelPattern {


This is probably a bigger conversation, but I wonder whether it makes sense to have a tabpanel pattern at all, since it doesn't actually do or render anything.

jelbourn · 2025-03-07T00:31:19Z

src/cdk-experimental/tabs/tabs.ts

+    'class': 'cdk-tabs',
+  },
+})
+export class CdkTabs {


Yeah, I think we should probably have a discussion on the API(s) we expect an end-developer to define for their own tab implementations, and then how to best accommodate that with the directives. FWIW I think we will have a requirement that there may be elements between the tablist and the tabpanel(s).

For content, I suspect these directives will need to end up being oriented around rendering <ng-template> content.

jelbourn · 2025-03-07T00:32:32Z

src/cdk-experimental/tabs/tabs.ts

+ *   <div cdkTabpanel>Tab content 1</div>
+ *   <div cdkTabpanel>Tab content 2</div>
+ *   <div cdkTabpanel>Tab content 3</div>


Do we have any info on whether having one tabpanel element for each tab is strictly necessary, or can there be one tabpanel that changes attributes/content?

cc @crisbeto I vaguely recall this has come up before but I don't remember the details. Do you happen to recall anything?

Hidden tabpanels should have at least aria-hidden attribute, from the accessibility tree perspective there will be only one tabpanel, so having one or one per tab are likely the same. Most of the ARIA examples have one tabpanel per tab due to the static content.

It's probably fine supporting both ways

 <div cdkTabs> <ul cdkTablist> <li cdkTab>tab 1</li> <li cdkTab>tab 2</li> </ul> <div cdkTabpanel>content 1</div> <div cdkTabpanel>content 2</div>  @for (tabpanel of tabpanels) { <div cdkTabpanel>{{tabpanel.content}}</div> } </div>  <div cdkTabs> <ul cdkTablist #tablist> <li cdkTab tab="tab1">tab 1</li> <li cdkTab tab="tab2">tab 2</li> </ul>  <div cdkTabpanel [tab]="tablist.selected...">{{getContent(...)}}</div> </div>

explaining the `inert` attribute

patterns

andrewseguin · 2025-04-09T19:48:19Z

src/cdk-experimental/tabs/tabs.ts

+    },
+  ],
+})
+export class CdkTabpanel {


nit: capitalize Panel so its CdkTabPanel

I am not sure if we want to keep the naming consistent with corresponding roles https://w3c.github.io/aria/#tabpanel

andrewseguin · 2025-04-09T19:48:48Z

src/cdk-experimental/tabs/tabs.ts

+  exportAs: 'cdTabcontent',
+  hostDirectives: [DeferredContent],
+})
+export class CdkTabcontent {}


nit: capitalize Content so its CdkTabContent

I think the decision relies on how we name CdkTabpanel

CdkTabpanel + CdkTabcontent
vs
CdkTabPanel + CdkTabContent

andrewseguin · 2025-04-09T19:58:24Z

src/components-examples/cdk-experimental/tabs/cdk-tabs/cdk-tabs-example.html

+    [focusMode]="focusMode"
+    [selectionMode]="selectionMode"
+  >
+    <li cdkTab class="example-tab">tab 1</li>


Should we enforce an "id" attribute to connect the tab and its panel/content? It's not easy to read which panel connects with which tab, except by counting them. E.g. consider 8 tabs with complex html here. React Aria does this id connection with tabs https://react-spectrum.adobe.com/react-aria/Tabs.html

Agreed that it gets more difficult to visually matching tabs and tabpanels when the tabs amount increases. The only potential risk with the explicit id matching is the developer provided ids are not guarantee unique, so it relies on developers to use the API correctly.

@wagnermaciel we had the discussion on this before and the conclusion was to keep the API as simple as possible. Do you think if we should support both explicit and implicit matching, or enforce one solution? Now the list selection supports a value for each item, so we can potentially use the value field as the tabs identifier.

andrewseguin · 2025-04-09T19:59:54Z

src/components-examples/cdk-experimental/tabs/cdk-tabs/cdk-tabs-example.html

+  <mat-form-field subscriptSizing="dynamic" appearance="outline">
+    <mat-label>Selection strategy</mat-label>
+    <mat-select [(value)]="selectionMode">
+      <mat-option value="explicit">Explicit</mat-option>


Using Explicit with "Active Descendant" doesn't let the user change tabs. Should we somehow disallow this combo, or rely on docs to make sure users dont combine those

andrewseguin · 2025-04-09T20:03:52Z

src/cdk-experimental/tabs/tabs.ts

+    'tabindex': '0',
+    'class': 'cdk-tabpanel',
+    '[attr.id]': 'pattern.id()',
+    '[attr.inert]': 'pattern.hidden() ? true : null',


Should we also go ahead and set the style display: none? Is there a reason why the user would want anything different

I'd recommend against setting any styles since even innocent seeming ones like display: none can end up with users overriding our styles (e.g. to do some animation). imo we should leave how the tab panel gets visually hidden up to the developer

+1 to Wagner's point. One example can be the tablist based Carousel Pattern, that the left and right hidden panels can be slightly faded and transformed without being visually hidden as long as the keyboard navigation makes sense to the screenreader users.

andrewseguin · 2025-04-09T20:04:53Z

src/cdk-experimental/ui-patterns/tabs/BUILD.bazel

+
+package(default_visibility = ["//visibility:public"])
+
+ts_project(


We should avoid using the glob when possible - just list out the source files

andrewseguin · 2025-04-09T20:09:43Z

src/cdk-experimental/ui-patterns/tabs/tablist.ts

+  toggle?: boolean;
+  toggleOne?: boolean;
+  selectOne?: boolean;
+  selectAll?: boolean;


What would these do: select (vs just selectOne), selectAll, toggle (vs just toggleOne)?

Are tabs every "multi-select"?

I think tabs can be multi-select, but we decided that's out of scope for this PR. We should remove all the multi-select language from here that was copied over from listbox

ok7sai requested a review from a team as a code owner February 28, 2025 18:20

ok7sai requested review from crisbeto and andrewseguin and removed request for a team February 28, 2025 18:20

angular-robot bot added the detected: feature PR contains a feature commit label Feb 28, 2025

wagnermaciel reviewed Feb 28, 2025

View reviewed changes

ok7sai force-pushed the ng-aria-tabs branch from 9fbf887 to 06dd309 Compare February 28, 2025 23:01

crisbeto reviewed Mar 3, 2025

View reviewed changes

ok7sai force-pushed the ng-aria-tabs branch 2 times, most recently from f82703c to eed8a03 Compare March 4, 2025 18:04

wagnermaciel requested a review from jelbourn March 4, 2025 23:43

wagnermaciel approved these changes Mar 5, 2025

View reviewed changes

jelbourn reviewed Mar 5, 2025

View reviewed changes

ok7sai force-pushed the ng-aria-tabs branch from 1181b5b to 14c3560 Compare March 6, 2025 17:48

jelbourn reviewed Mar 7, 2025

View reviewed changes

ok7sai force-pushed the ng-aria-tabs branch 2 times, most recently from c87bd4c to 91dacdf Compare March 13, 2025 21:30

ok7sai force-pushed the ng-aria-tabs branch from 91dacdf to a9685f5 Compare March 26, 2025 08:59

ok7sai added 12 commits April 8, 2025 14:57

feat(cdk-experimental/ui-patterns): tabs ui pattern

448012d

Remove multiselectable part from tabs ui pattern

00b7b62

Add JSDoc to cdk tabs directives

00441aa

Addressed comments

ff7556b

Replaced aria-hidden with inert

b1e86d6

Addressed comments

70b8721

Removed selectedIds from CdkTablist

af1c21a

Removed unused index from tab ui pattern

c1776c4

Moved from Signal type to SignalLike type

442ba96

Replaced unnecessary computes with pure functions, and added comment

3a67350

explaining the `inert` attribute

Added lazy/deferred content directives to be used in collapsible

ed83478

patterns

Migrated build targets to ts_project

5ff1b6e

Migrated build targets to ng_project and fixed breakage

f3b2478

ok7sai force-pushed the ng-aria-tabs branch from a9685f5 to f3b2478 Compare April 8, 2025 18:01

andrewseguin approved these changes Apr 9, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(cdk-experimental/ui-patterns): tabs ui pattern #30568

feat(cdk-experimental/ui-patterns): tabs ui pattern #30568

ok7sai commented Feb 28, 2025

jelbourn Mar 5, 2025

ok7sai Mar 5, 2025

jelbourn Mar 7, 2025

jelbourn Mar 5, 2025

jelbourn Mar 6, 2025

jelbourn Mar 7, 2025

jelbourn Mar 7, 2025

ok7sai Mar 7, 2025

andrewseguin Apr 9, 2025

ok7sai Apr 10, 2025

andrewseguin Apr 9, 2025

ok7sai Apr 10, 2025

andrewseguin Apr 9, 2025

ok7sai Apr 10, 2025

andrewseguin Apr 9, 2025

andrewseguin Apr 9, 2025

wagnermaciel Apr 9, 2025

ok7sai Apr 10, 2025

andrewseguin Apr 9, 2025

andrewseguin Apr 9, 2025

wagnermaciel Apr 9, 2025


		package(default_visibility = ["//visibility:public"])

		ts_project(

feat(cdk-experimental/ui-patterns): tabs ui pattern #30568

Are you sure you want to change the base?

feat(cdk-experimental/ui-patterns): tabs ui pattern #30568

Conversation

ok7sai commented Feb 28, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment