<rh-tab for="dom-id"> - separating tabs from their associated panels in the DOM

[bennypowers]

The classic case of rh-tabs (or it's older cousin pf-tabs) looks like this:

<!-- One big ole' rectangle -->
<rh-tabs>
  <rh-tab>Hello</rh-tab>
  <rh-tab-panel slot="panel">World</rh-tab-panel>

  <rh-tab>Bonjour</rh-tab>
  <rh-tab-panel slot="panel">Tout le monde</rh-tab-panel>

  <rh-tab>Shalom</rh-tab>
  <rh-tab-panel slot="panel">Aleichem</rh-tab-panel>
</rh-tabs>

This works, but BEHOLD: the whole tabs system is a single rectangle, and we can't put content between the tab bar and the active tab panel, and we can't really add new semantics to the tab bar. Compare with this aspirational snippet:

<!-- Two rectangles! -->
<header>
  <nav>
    <rh-tabs>
      <rh-tab for="hello">Hello</rh-tab>
      <rh-tab for="french">Bonjour</rh-tab>
      <rh-tab for="hebrew">Shalom</rh-tab>
    </rh-tabs>
  </nav>
</header>

<main>
  <p>I'm intercalated content, for some reason.</p>
  <section>
    <h2>Heading</h2>
    <rh-tab-panel id="hello"  slot="panel">World</rh-tab-panel>
    <rh-tab-panel id="french" slot="panel">Tout le monde</rh-tab-panel>
    <rh-tab-panel id="hebrew" slot="panel">Aleichem</rh-tab-panel>
  </section>
</main>

☝️ pick apart my awful semantics up there, sure; BUT we'd probably want to allow the header and nav semantics on the tab bar.

@nikkimk @brianferry thx for helping me think this through
@zeroedin welcome back from PTO 😉 and IIRC we discussed this previously: apologies if this discussion already lives somewhere else, I was unable to find it.

[markcaron]

I'm gonna add my $0.02 for whatever it's worth in today's market 😅

1. I can see the use case, not just in our docs templates, but in other potential cases to have the ability to separate tabs from their panels due to structural requirements.
2. I think the above code seems reasonable, but we'd want to discourage situations where a heading would be between the tabs and the panels. Separating them like this opens up the "abuse" concern @nikkimk mentioned in standup.

Instead, we'd simply want:

<!-- Two rectangles! -->
<header>
  <nav>
    <rh-tabs>
      <rh-tab for="hello">Hello</rh-tab>
      <rh-tab for="french">Bonjour</rh-tab>
      <rh-tab for="hebrew">Shalom</rh-tab>
    </rh-tabs>
  </nav>
</header>

<main>
  <rh-tab-panel id="hello" slot="panel">World</rh-tab-panel>
  <rh-tab-panel id="french" slot="panel">Tout le monde</rh-tab-panel>
  <rh-tab-panel id="hebrew" slot="panel">Aleichem</rh-tab-panel>
</main>

On the flip side, there is a certain beauty to the noscript / fallback of the original spec (i.e. tab + panel, tab + panel) that gets lost when they're separated.

[zeroedin]

@bennypowers we had this conversation on the side when discussing adding explicit relationships functionality. This opens that conversation back up.

I also agree with @markcaron about not having content such as a heading between tabs and the panel when detached. I feel like we are straying away from the general role of tabs and more into what is navigation semantics for the sake of the look and feel of the tabs with SPA like functionality.

Tabs with explicit relationships as children

  <pfe-tabs id="explicit">
    <pfe-tab slot="tab" aria-controls="panel-1">1</pfe-tab>
    <pfe-tab slot="tab" aria-controls="panel-2">2</pfe-tab>
    <pfe-tab slot="tab" aria-controls="panel-3">3</pfe-tab>
    <pfe-tab slot="tab" aria-controls="panel-4">4</pfe-tab>
    <pfe-tab slot="tab" aria-controls="panel-5">5</pfe-tab>

    <pfe-tab-panel id="panel-5">5</pfe-tab-panel>
    <pfe-tab-panel id="panel-4">4</pfe-tab-panel>
    <pfe-tab-panel id="panel-3">3</pfe-tab-panel>
    <pfe-tab-panel id="panel-2">2</pfe-tab-panel>
    <pfe-tab-panel id="panel-1">1</pfe-tab-panel>
  </pfe-tabs>

What you are now proposing would look something more like this:

Tabs with explicit relationships and detached panels

  <pfe-tabs id="detached">
    <pfe-tab slot="tab" aria-controls="detached-1">1</pfe-tab>
    <pfe-tab slot="tab" aria-controls="detached-2">2</pfe-tab>
    <pfe-tab slot="tab" aria-controls="detached-3">3</pfe-tab>
    <pfe-tab slot="tab" aria-controls="detached-4">4</pfe-tab>
    <pfe-tab slot="tab" aria-controls="detached-5">5</pfe-tab>
  </pfe-tabs>

  <pfe-tab-panel id="detached-5">5</pfe-tab-panel>
  <pfe-tab-panel id="detached-4">4</pfe-tab-panel>
  <pfe-tab-panel id="detached-3">3</pfe-tab-panel>
  <pfe-tab-panel id="detached-2">2</pfe-tab-panel>
  <pfe-tab-panel id="detached-1">1</pfe-tab-panel>

I wonder if we should use aria-controls here as the link instead of for

The for attribute is an allowed attribute for <label> and <output>. When used on a element it indicates the form element that this label describes. When used on an element it allows for an explicit relationship between the elements that represent values which are used in the output.

MDN: HTML attribute: for

[zeroedin]

I'm looking for any other design system that shows a similar pattern with a detached tab panels idea, below are the design systems I took a look at.

Duet - No
Nord - No
Shoelace - No
Open UI - Maybe? - Supplemental content: Offers a way to add content via start and end to the left and/or right (depending on language region) of the tab list. (I'm not convinced this is the same idea)
Lion - No
Edison - No
FAST - No
Bootstrap - No

Then there is also the Inclusive Components tabbed interface article, which bolsters my thoughts I'm having about this pattern that just does not seem the right fit. Is it a tabbed interface that should be used in the context of ux. or should it be a TOC? Specifically the paragraph with the quote from Jeremy Keith:

In Chapter 2 of his book, Resilient Web Design Jeremy Keith talks about material honesty; that "one material should not be used as a substitute for another." In this case, we'd be making a table of contents appear like a tab list. We should avoid this since users who see tabs expect certain behaviors not offered by a simple list of links.

As well as the section When panels are views which is how we are sort of treating them in this detached context.

I'm still struggling to figure out where this pattern fits, if at all.

To me, it feels like this is better served to the user as a #anchor nav. If it is truly about hiding each section why not just a normal nav with sub-pages? If we want fancy then should it be a SPA functionality with a router then? I'm just trying to better understand the problem we are solving by having the panels disconnected from the tab container.

Please change my mind and help me better understand if I'm missing something.

[bennypowers]

thanks for the notes, that reads super clear to me. In consideration of the above, for ux-dot I'd like to remove the tabs, use links, render subpaths, and skip the spa shenanigans altogether.

I'm not convinced we can't find a use for separate tablist and panels though, regardless of the above, so let's continue this discussion for a bit and see what shakes out.

[hellogreg]

This topic got me flipping through Inclusive Components, too! I'm with @zeroedin and @nikkimk (and Heydon and Jeremy in IC) in thinking that this sounds to me like a case for anchors. If you do find some reasons for detaching tabs and panels, there may be some additional a11y considerations (e.g., ensuring that there are still both programmatic and visual cues associating the two sections).

[bennypowers]

thinking through the nav links version of tabs. if we disallow the nav-links version of tabs, then users are going to do what I said above and implement the designs themselves. so then why do we have a design system? What i mean here is that rh-tabs should also support the nav-links semantics described by @zeroedin and @hellogreg above. As a straw proposal, I suggest adding a semantics attribute, which would default to tablist, and let the user choose a "preset theme" for a11ty semantics:

<rh-tabs semantics="nav">
  <rh-tab><a href="overview/">Overview</a></rh-tab>
  <rh-tab><a href="design/">Design</a></rh-tab>
  <rh-tab><a href="code/">Code</a></rh-tab>
</rh-tabs>

specifically, semantics="nav" would allow for tabs that are not connected to panels
we don't have much to lose here, since tabs always requires javascript anyways.

[zeroedin]

Sorry if it feels like I'm bikeshedding here, not intentional, but I still think this use case feels more like a possible extension of horizontal jump links/ table of contents rather than tabs for this use case. Your last example above doesn't show the panel so can you clarify if that example would even have a related panel or not?

Tables of content
Tables of content are navigation for related pages or page sections and should be semantically similar to main site navigation regions, using a <nav> element, a list, and a group labeling mechanism.

https://inclusive-components.design/menus-menu-buttons/

Jump links/ TOC (horizontal) component in both RHDC design spec and patternfly v4:
https://xd.adobe.com/view/d20a1c17-375c-4c7f-6827-5fe2f8c2d92f-a43b/screen/eae7f769-916b-4a4d-8c8c-0f82c82f1128/specs/

https://www.patternfly.org/v4/components/jump-links/html

On patternfly's website they use the tab look and feel for their component page top nav and while it is their tab component, technically, it is a routered nav and not what I would call a traditional tabbed interface as it doesn't have a panel association. Did they make this code association for that very style-sharing simplicity?

https://www.patternfly.org/v4/components/tabs/htm Just as a reference their HTML demos do not include panels at all for their tabbed navigation variant.

The look a feel is shared and they are directly sharing the styles from the tab component but I wonder if we should conflate the same idea with what we are calling tabs? To me, this is more like a tertiary-nav component with a look a feel that mimics tabs rather than carrying all the JS baggage of tabs. That is if it doesn't have that panel relationship which is what I think defines tabs as a component. It could even be as I mentioned above an extension of TOC that has external or routed links?

[hellogreg]

To me, this is more like a tertiary-nav component with a look a feel that mimics tabs rather than carrying all the JS baggage of tabs. That is if it doesn't have that panel relationship which is what I think defines tabs as a component. It could even be as I mentioned above an extension of TOC that has external or routed links?

This is basically how I conceptualize it, too.

[bennypowers]

so we're talking instead of this:

<rh-tabs semantics="nav">...</rh-tabs>

something like this:

@customElement('rh-tertiary-nav') class RhTertiaryNav extends RhTabs {}

?

[nikkimk]

if we disallow the nav-links version of tabs, then users are going to do what I said above and implement the designs themselves.

I don't think they'll create their own as long as we provide tertiary nav as a component. I think disallowing it is the stick and tertiary nav is the carrot. If there is a tertiary nav, then we have made it easier to use than building something from scratch.

[markcaron]

We've decided to move away from the "detached" tabs in favor of a Subnav, which will be a simpler version (in look and functionality) to Secondary Nav.

See issue #703 for rh-subnav