Panels and panelsets

There is a school of thought that says there is a common interaction pattern across many of the visual design patterns we use regularly on the web (carousels, accordions, tabs etc.). In an effort to simplify implementation for developers, improve responsive design support, and improve consistency for users, a proposed specification has emerged.

There is an article on Radar that introduces the general idea:

There is also a draft specification that defines the proposed elements and attributes: https://specs.webplatform.org/common-panel/bkardell/gh-pages/

With some prollyfill prototypes to play with: https://bkardell.github.io/common-panel/prototype/panelset-element.html

Comments, ideas, suggestions, bugs and other useful things are very much welcome. Please respond here, or file as issues on Github:

Thanks.

Was there any motivation of why using: <paneltitle> over <header>?

I know that means the code would be likely another tag:

<panel>
  <header>
    <h1>Panel title</h1>
  </header>
</panel>

Instead of:

<panel>
  <paneltitle>Panel title</paneltitle>
</panel>

However it would reduce the number of tags needed to implement in browsers etc. Is there any other reason the new tag was created?

Would it also make sense to make <panel> a sectioning content?

There was a whole whole lot of talk about whether/what these could be, I kind of wish we’d captured all of that debate in text/notes form. Trying to sum something up but @LJWatson and @SteveF can probably do better…

A panel itself has similarities to a number of elements, but not complete overlap with any of them - this is actually often the case with new elements I think, so that shouldn’t really be surprising. Pretty early on it was decided that it isn’t sectioning and doesn’t belong in an outline or anything like that. Also, Panel titles have a shadow dom (as least per the proposal) which allow them to potentially contain affordances to open/close or even dismiss/removed from the dom the panel that they control. Headers obviously don’t have those things as it stands right now. My original plan had a simple title attribute, but this had a number of problems and we revisited it.

After reading the whole linked article and this thread, I struggle with seeing the need for it. I don’t see a particular benefit over what we already have apart from having another semi-targeted element. Semi-targeted because it can be used for a variety of things you say, as slider, accordion, toggle. Each of that can already be solved by existing markup, in an accessible, semantic way. On the other hand, approaches like this have been mentioned every so often as a use case for web components, which makes also more sense to me for a carousel, accordion, toggle.

I struggle to see summary/details replaced by panel/paneltitle. To me summary details is not a toggle but a semantic way to describe a summary text and give details in a related container. With panel and paneltitle this is probably not the same (it could be but then again, why should we replace it as we already have semantic elements for it).

Currently, I for a typical carousel or accordion I use:

section
  > ul
    > li
      > h3
      > p
    > li
      > h3
      > p

and a few more aria attributes that explain some the logical references. I can’t see how panel can get rid of the aria attributes. I don’t know why we should use paneltitle instead of h3/h4 heading which are semantically correct already and appreciated by every parser (search, rss, markdown, etc).

Please don’t get me wrong, if there is something I missed here, let me know. I’m cool with things that help web developers write better code but currently I couldn’t see any advantage over an already existing approach.

@jonathank @briankardell

If memory serves, another reason was that <header> is intended to contain navigational content such as <nav>, <h1> through <h6>, links and such. That wouldn’t be appropriate within the context of the visual metaphors like tabs or accordions.

@helloanselm

Thanks for taking time to think about this. It’s really helpful

We’re trying to make things even easier for developers. You’re right, we can create all these things using existing markup, but that still takes work by the developer.

We could do-away with the ARIA because we’d map the required roles/attributes to the new elements. Much like <a> has an implicit role of “link”, <panel> might have an implicit role of “panel” (or whatever we call it).

This simplifies the markup considerably. For example, instead of:

<ul role="tablist">
<li role="presentation">
<h3 role="tab" id="t1" aria-selected="true" aria-controls="p1">Title</h3>
<p role="tabpanel" id="p1" aria-labelledby="t1" aria-hidden="false">Content...</p>
</li>
...
</ul>

You’d only need:

<panelset>
<panel>
<paneltitle>Title</paneltitle>
Content...
</panel>
...
</panelset>

ARIA is also a bit limited for our purposes. It has roles/attributes for tabs, which can be duplicated for accordions, but nothing generic enough to cover all the possible visual metaphors. We could mint some new ARIA roles/attributes, but if we’re going to invent something new, making it native to the host language seems like a good way to do it.

With support for the proposed elements, the browser would also shoulder some of the interaction load. If the browser provides support for keyboard/mouse/touch interaction, it saves developers from having to do it through scripting.

The last piece of the developer puzzle is that it should be easier for responsive design. It’s possible to transform a custom set of tabs into an accordion in response to a mobile breakpoint, but it’s pretty horrible to have to do it. With native HTML elements and a common interaction, this should get much easier.

“The arrow keys should allow the user to navigate panels which open automatically, adding their content’s ability to receive focus. TAB should move the focus from title to open content and then to the next focusable thing after the common-panel-set.”

The issue of my page scroll (up down arrows) being hijacked into selecting tabs (titles) is still an issue (similarly jQueryUI codes it). Allowing only PageUp/PageDown to move the page diminishes usability, as context between sentences right at the page edge is easily lost. It would be nicer if only left/right arrows were able to affect tab (title) focus.

That aside, I otherwise like this keyboard paradigm better than what I’m currently hearing for tab-panels: that only arrows let users move between/select tabs and that focus should automatically move to the open panel (or something focusable inside it).

This new proposal is much more friendly to general and newbie keyboarders, who expect to be able to tab between tabs and don’t expect to have to shift-Tab out of a panel simply because it opened, while also allowing them to decide if they want to enter a tab or try out arrows. Meanwhile the arrows continue a known UI pattern for many other users.

Hm. I had one of those “drank a lot and tossed and turned all night and kept thinking this” kinda nights, about mega menus.

In many ways, mega (navigation) menus fall under many of the ideas for the panel setup:

• on desktop they have (or are supposed to have) similar behaviour as an exclusive-panel setup (one panel/submenu open at a time)
• on mobile they are often collapsed into accordions
• also, devs use all sorts of weird stuff when trying to decide what roles they should use (I think aria-expanded might be the most popular now for letting users know a submenu panel is open?)

They’re not usually turned into carousels or slide decks, but carousels and slide decks are often written as image-filled ul>li>a navigation, with on mobile sometimes the separate set of controls being removed (and swiping the main list directly instead).

Now besides the obvious problem of mega menus being considered (and built as) just more fancy and more content-filled regular dropdown menus (lists of links, a known and working paradigm that doesn’t need to change), which have an established set of HTML, and also has the currently unresolved issue/problem of, “We don’t know how to deal with the top-level anchors doubling as do-stuff buttons and go-somewhere anchors” (if we stick to the pattern presented here with the panels, users would still only tab/arrow around main menu items to move focus which displays the submenu, while actually clicking (hitting Enter) would trigger the anchor, then it solves this), but there’s also the idea that when we create a tab-panel or a carousel, when we remove Javascript, ARIA and some CSS this degrades down to

• a group of in-page skip links, next to
• a list of content chunks the skip links point to

Navigation mega menus, as well as current (if well-built) tab-panels, carousels and accordions degrade normally into this pattern (except that megas are nested). Important is to notice that in the degraded pattern, the “titles” are anchors, pointing to some destination, with native focus and click listeners. The skip links can seem silly when the panels are tiny but they’re useful when panels get long.

So in this thought experiment, for panel titles, I wonder if "DOM interface: Uses HTMLElement ??"

needs to go further, more towards something that gets native focus and maybe even has a destination?

And the other thing I wondered, is… do I see two things going on?

• a single structure we’re using to build lots of things, controlling names and showing/hiding content (the reason for this idea to make a unifying set of HTML)

but also, separately

• a single set of behaviour (users interact with controlling names to hide/show associated content)

Megamenus (where not only links but other content like headings and images are in the submenus) have (or generally should have) similar behaviour to this proposal, but quite different HTML structure. In Megas, the submenus are nested into the list-items and are siblings to the anchors (and the anchors don’t point to their siblings but usually off-page). In panels, the controllers are in separate lists from the content and are siblings. So the aria stuff tends to be very different despite the similar behaviour and keystrokes (just add :hover to the panels and accordions to complete it). A developer asked to build a mega-menu before s/he’s given any link destinations would have to wonder if they really just want to buid a tab-panel/accordion. The choice between the two structures then seems entirely based on “do the main-level links have real destinations.” On some websites, they don’t. They just have href="#".

It would be nice if, despite two slightly different structures, if there were a way for devs to say "For this structure I expect is-a sets of roles (controllers and content) and has-a sets of states (selected or not, content visible or not) and does-a sets of behaviour and listeners (what does focus, arrow key, hover and touch do).

Or, let’s say these panels went somewhere: aren’t some developers going to look at panel structure and try writing mega-menus as tab-panels (but then with external anchors) instead of nested lists?

This has just been bugging me all night. Maybe mega menus are not larger and more fabulous list-based navigation menus. Maybe they’re controller-panels. Except that you can also go somewhere too. Panels that navigate.

First of all, I think this is a great idea. Separating interaction paradigms from presentational ones is very wise and this seems like a suitably generic, extremely malleable proposal. So much of our DOM interaction is about showing and hiding selected content; filtering what’s available in the document at any one time.

Having read the extension spec (https://specs.webplatform.org/common-panel/bkardell/gh-pages/), which is already promising, I think there’s possibly more that could be done to make authorship easy and the interaction versatile.

I think if we were to implicitly associate <paneltitle> elements with <panel> elements by index within <panelset>, then we could make tab interfaces and simpler “disclosure” groups just by changing the arrangement of elements:

<!-- tab interface -->
<panelset>
  <paneltitle>Tab 1</paneltitle>
  <paneltitle>Tab 2</paneltitle>
  <paneltitle>Tab 3</paneltitle>
  <panel>...........</panel>
  <panel>...........</panel>
  <panel>...........</panel>
</panelset>

<!-- disclosure group -->
<panelset>
  <paneltitle>Title 1</paneltitle>
  <panel>...........</panel>
  <paneltitle>Title 2</paneltitle>
  <panel>...........</panel>
  <paneltitle>Title 3</paneltitle>
  <panel>...........</panel>
</panelset>

The indexes are consistent per element regardless of the layout, so identifying the corresponding <panel> to toggle would be effortless. Note that my example differs by having the titles outside their panels. I think this is more robust and versatile. For a carousel style widget, I might have the “pips” to toggle the content panels under the set of <panel>s. This is a simple reversal of the tab interface example:

<panelset>
  <panel>...........</panel>
  <panel>...........</panel>
  <panel>...........</panel>
  <paneltitle>Pip 1</paneltitle>
  <paneltitle>Pip 2</paneltitle>
  <paneltitle>Pip 3</paneltitle>
</panelset>

I actually don’t think there’s any need for prefereddisplay. The heart of this is just showing and hiding content by index. Styling could be anything. However, one attribute might go a long way: exclusive. By putting exclusive on the parent <panelset> only one <panel> would be shown at a time. In the disclosure configuration, above, the widget would then act like an accordion, hiding all <panel>s except the one for which you’ve clicked/triggered the <paneltitle>.

<panelset exclusive>
  <paneltitle>Title 1</paneltitle>
  <panel>...........</panel>
  <paneltitle>Title 2</paneltitle>
  <panel>...........</panel>
  <paneltitle>Title 3</paneltitle>
  <panel>...........</panel>
</panelset>

This would apply to most patterns including tab interfaces and gallery / carousel type widgets, so maybe the attribute should inexclusive or something, reversing the behavior.

I’m not sure I follow the expansionState attribute, but it occurs to me that it should be on the <paneltitle> element rather than the <panel>. Maybe this was intended already, but if only for styling purposes, it would be beneficial, I think.

paneltitle[expansionState="opened"] {
  color: $highlight;
}

I may be missing something, but this seems verbose. Why not just opened as a boolean?

I agree with @heydonworks here that it may offer more flexibility to allow the <paneltitle> to exist outside of the <panel> it refers to.

One worry I do have, however, is how much stylability is offered. How much influence would a developer have, for instance, over how a <panel> is shown then the related <paneltitle> is activated, if the actual interaction is (if I understand it correctly) up to the user agent itself? For instance, what if a developer wanted to have the various <paneltitle> elements shown in a page, and when one is activated, they want the <panel> to animate from off-screen left and ease towards the centre of the browser window? Or having a soft cross-fade between different <panel>s? Or any other visual effect, really? This is one of the reasons many devs still prefer to use their own home-brewed code, jQuery/jQueryUI, or third party libraries…full control over the visual aspect. At the very least, there must be some way for devs to either rely on the UA to do some form of “default” show/hide, as well as a way to explicitly control all these aspects themselves, I’d say.

This is exciting! I’d love to see a value for the preferred-display attribute that allowed for a “blown out” or “expanded” state… meaning all items are not collapsed or visually hidden and could be consumed by all users without interaction. e.g. none?

<common-panel-set preferred-display="tabset|carousel|accordion|none">
	...
</common-panel-set>

or

#foo {
	--preferred-display: tabset|carousel|accordion|none; 
}

A scenario that could support this request would be all panels are expanded/visible/digestible by all users on smaller screens and at a certain breakpoint it could snap into one of the patterns via media queries & --preferred-display: accordion;

I also believe more developers would adopt an approach like this if browser manufacturers did not inject (Shadow DOM) objects into the patterns that can’t easily be styled and if it was easy to introduce CSS-based animation.

An handle for a tabbed content or accordion area is a navigational element. So this sounds like a reason to use <header> in panels.

@feeela "An handle for a tabbed content or accordion area is a navigational element. So this sounds like a reason to use in panels."

Given that <header> can contain multiple navigational mechanisms, how do you think the pertinent control for the <panel> might be identified if we opted to use <header>?

@heydon Thank you for so many ideas!

An immediate question about placing the <paneltitle> outside of the <panel>… How do you envisage this working in terms of responsive design? Morphing from a set of tabs to an accordion/set of disclosures for example?

preferrred-display is really nothing more than an attribute indicating a preference that no one is really required to implement - however, given it authors and/or browsers can add CSS hooks to style it up via simple name associations. Without this attribute you’d get a standard view defined by the browser (accordion probably that’s how it is in the prototype because they work equally well everywhere, but maybe something more like a deck on a very very small device). It almost could have been a class but it’s kind of integral in a sense to the idea and browsers don’t really do such a thing (ship pre-fab class definitions), and we want you to be able to easily express that it changes at breakpoints - i.e. with a large viewport show tabs, but with a smaller one show an accordion and CSS will never do that with classes because it would create cycles - but it could potentially with a narrow property.

@briankardell tnx! that makes sense

The name is entirely bikeshed-able, but it’s the larger concept of panel that is opened or closed, not the title, right? specifically, it has impacts on both the title (a11y wise and visually - it might flip a toggling icon or a background color) and the content (a11y wise and visualy - visibility, z-index, etc can be controlled there). As to why it’s not just boolean it’s because it plays a dual role - some panels aren’t open/closeable, having an attribute at all lets us know that it is user-controllable, and then there’s the two choices of state. For me, it was mostly an effort to not confuse existing authors by conflating with any of those other attributes that this winds up controlling, but this is just a starting point so it’s open to change.

Yes. The panel would open and close by pressing the title. Hence, the title itself should tell the user if the corresponding panel is (then) in an open state or not. I was thinking in terms of something similar to aria-expanded where aria-expanded="true" would be on a button so that when it is focused it would say “toggle button expanded”, meaning the thing the button controls is expanded.

@heydonworks yes, this is what I am saying – the aria-expanded=true is reflected, and more too (as I explained). Setting the state of the panel manages all of that.

@jonathank @briankardell

If memory serves, another reason was that <header> is intended to contain navigational content such as <nav>, <h1> through <h6>, links and such. That wouldn’t be appropriate within the context of the visual metaphors like tabs or accordions.