Panelset & tabs: defining separate goals for each pattern

@bkardell and I went through a number of examples of more traditional application tabs and examples of the proposed panelset pattern, and came up with a proposal to separate them into two different platform-level solutions with discrete purposes and use cases, outlined below.

---

Through a lot of discussion and looking at examples, as well as based on evidence in existing UI toolkits, we believe that there is a need for two separate solutions for something that many users would just call 'tabs'. In this document we're attempting to explain the differences between them, what their uses are and offer some working terminology.

There may or may not be implementation detail overlap between these ideas, but their basic purpose, limits and likely semantics would differ. They probably benefit from work happening in parallel to coordinate similar APIs in areas like CSS pseudo-selector naming or open/close DOM attributes.

Statement of purpose for each element

A brief description of the basic purpose and functionality of each proposed element.

Application tabs

The primary purpose of application tabs is to allow users to easily switch between multiple possible panes of content that are specifically not intended to be viewed at the same time. As such there are functional differences, covered in more detail in the next section. Possible examples include browser tabs, file tabs in a code editor, multiple views within an app such as map/list, or email/calendar/contacts.

Some implementation challenges that a tabs element could solve for authors include:

• Semantics
• Keyboard interaction
• Close buttons
• Tablist overflow

Panelsets

The primary purpose of panelsets is to provide a mechanism to reflow multiple sections of content between a tab-like one-at-a-time presentation and a linear, sequential presentation. So in essence, the visual title/content ordering for multiple sections may switch between these two options:

1. Title 1, Title 2, TItle 3
   Content #

2. Title 1, Content 1
   Title 2, Content 2
   Title 3, Content 3

Visually, the first option could be presented as tabs, a carousel, or anything with a similar content-switching interface.

The second option could be presented as accordions or simply linear content.

Some implementation challenges this element or elements could solve for authors include:

• Reordering of content on the page when reflowing between two presentations
• Automatically triggering a change in presentation based on container size
• Changes in interaction between switching out a content pane vs. expanding/collapsing multiple panes
• Potentially changes in semantics between the two presentations (depending on whether we can find a set of semantics that would work for each case)

Differences between Tabs and panelsets

• When printing, tabs would only print the currently shown tab content, while panelsets may have the ability to print all content, regardless of the current onscreen presentation
• Search in page and similar functionality: panelsets would search all content, tabs would only search the currently open content
  panelsets would not have built-in dismiss or close functionality
• Because their purpose is centered around reflow, panelsets are designed around around optional progressive enhancement and provding meaningful content even in the absence of support or script enablement. This is not generally an option for, or as important to many uses of application tabs.

Examples

Application tabs

1. Code editor: This shows probably the most traditional tabs, together with a currently hard-to-solve author problem, a close button per tab.
   

2. Write vs. preview tabs in a compose box on github:
   

3. Tabs that progressively collapse behind an overflow menu in github, another current implementation challenge for authors.
   
   (shown above uncollapsed)
   
   (shown above collapsed)

4. Vertical tabs with an overflow menu in google docs
   

5. Slack: Notable because it's tabs in collapsable sections.
   

Panelsets

1. Tabs to accordion presentation:
   
   

2. This one switches between presentations in the opposite way to most other examples, with tabs at a small screen, and linear order at a larger screen:
   
   

3. Tabs to accordions: Wolvic.com is a website primarily used by XR devices with mostly fixed width windows, however, the sizes can differ substantially. It should vertical tabs when that is pragmatic, but as a series of collapses when it isn't.
   
   

4. Michigan.gov drivers license renewal shows vertical tabs to the left on a wider screen, but regular "top" tabs on a smaller screen. Several other variants could fit just as well and the 'one-at-a-time' view is secondary.
   
   

Start by reading the proposed distinctions between application tabs and panelsets, then review the examples and stated implementation challenges in this issue. No source files, tests, or implementation entry points are identified; completion would require an agreed platform-level direction, terminology, and scope for the two solutions.