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

[ok7sai]

No description provided.

[jelbourn]

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.

[ok7sai]

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.

[jelbourn]

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]

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

[jelbourn]

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]

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]

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?

[ok7sai]

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

<!-- For static tabs -->
<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>
  <!-- Or structural directives -->
  @for (tabpanel of tabpanels) {
    <div cdkTabpanel>{{tabpanel.content}}</div>
  }
</div>

<!-- Or for deferred content -->
<div cdkTabs>
  <ul cdkTablist #tablist>
    <li cdkTab tab="tab1">tab 1</li>
    <li cdkTab tab="tab2">tab 2</li>
  </ul>

  <!-- Just an ideal, CdkTablist does not expose selection yet. -->
  <div cdkTabpanel [tab]="tablist.selected...">{{getContent(...)}}</div>
</div>

[andrewseguin]

nit: capitalize Panel so its CdkTabPanel

[ok7sai]

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

[wagnermaciel]

+1 for CdkTabPanel. I think it's the more intuitive name here. Worth double checking what other libraries have done

[ok7sai]

TabPanel is used in React Aria, and Radix uses TabContent instead, so I guess capitalizing Panel and Content make sense. Let me address this.

[andrewseguin]

nit: capitalize Content so its CdkTabContent

[ok7sai]

I think the decision relies on how we name CdkTabpanel

CdkTabpanel + CdkTabcontent
vs
CdkTabPanel + CdkTabContent

[andrewseguin]

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

[ok7sai]

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.

[wagnermaciel]

I think enforcing an id would be a valid approach. I think the majority of tabs I've seen have been 3-4 in size so I think there's value in simplicity, but if we think it'll end up being a footgun for users then it's better to take the verbose approach at all times.

[andrewseguin]

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

[ok7sai]

Styling the focus state with aria-activedescendant is currently unimplemented. The listbox demo has the same issue AFAIK. This combo should be allowed, and we just need to figure out a way for developers to style the focus state.

@wagnermaciel any thoughts? we can apply a class like cdk-focused or cdk-focus-indicator to directives that are focused but not necessary selected and let developers style based on these classes. Or we can provide inputs like focusedClass="..." to allow developers apply their owned classes (can be useful for applying tailwind classes?)

[wagnermaciel]

That wouldn't be necessary for people using tailwind
https://tailwindcss.com/docs/hover-focus-and-other-states

I think adding a class makes sense, but I would propose calling it "active" instead of "focused"

[ok7sai]

Using aria-activedescendant means the child element won't receive the actual focus, so I don't think the tailwind util class like focus: would work. (The same reason today that :focus selector doesn't work for aria-activedescendant + explicit combo)

[wagnermaciel]

Ah shoot, you're right. For now I'd say just roll with adding the extra class. We can have a separate discussion on whether we want to tailor a solution for tailwind

[ok7sai]

I'd suggest let's hold the changes to the next PR to fix both listbox and tabs at the same time.

[andrewseguin]

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

[wagnermaciel]

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

[ok7sai]

+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.