Panels and panel sets

Picture a modern web application. It almost certainly uses interactive controls, perhaps a carousel at the start, probably a set of tabs or an accordion, or maybe it is based on a coverflow or deck. These are common user interface metaphors: if you use these terms, designers know what you mean, and people recognize and know how to use them. At first glance these design patterns seem to have quite different characteristics, but we’d like to convince you that they really aren’t so different after all.

Ok, convince me!

The idea of a panel of content comes from the printing industry. In printing, a panel is a single page of a brochure, or one face of a folded leaflet. A print panel might be visually unique, like the cover of a leaflet, or be like other panels in a set, like the inner faces of the leaflet.

The concept of a panel has been applied to web design multiple times, generally becoming interactive along the way. Panels of content can be expanded or collapsed, removed completely, or presented in collections. Each of these design patterns has a common purpose: display a collection or set of things, generally one at a time to save on screen space. They may cycle vertically or horizontally, or peel off in layers, but these transition effects do not change the fundamental purpose of the thing – to navigate effectively through some pieces of content.

We can see the relationship between these design patterns even more clearly when we think about accessibility. ARIA 1.0 gives us a way to mark up a set of tabs, and explains that the same markup can be used for an accordion as well. For responsive design, this equivalence becomes a real asset. A carousel of images with 3D effects on a desktop wide screen can be presented as a deck of small images on a phone touch screen.

Why does this matter?

Thomas Edison said that genius was 1% inspiration and 99% perspiration. As a prolific genius, we can probably take his word for it. On the web it is certainly true. But there is a problem.

When we invent something new, we have to build it. Then thousands of developers write code to do much the same thing, except with slight variations and changes. This is how we innovate and design patterns emerge. But when the task has become routine (like implementing a tab set or carousel), the inconsistencies bother users and it creates more work. Libraries have helped reduce the rate at which we reinvent the wheel, but there are many libraries each with their own inadvertent and deliberate differences. As well as compatibility headaches for developers trying to choose a set of tools, these differences mean that people can never quite be sure how something will work.

When we get to this point on the web it is useful to have a common standard: a consistent way to create these patterns, with consistent interactions that people are familiar with. It is true that browsers implement standards in subtly different ways, but whereas people might use many different websites or applications during the course of a day, they will only change browsers once or twice (between their smart phone and a laptop for example). A common standard doesn’t solve all the problems, but it does make things easier for both developers and users.

So what’s the idea?

In late 2014, Brian Kardell, Steve Faulkner, Chaals McCathie Nevile and I were chatting at TPAC. Brian had been thinking for some time about the fact that tab sets, carousels, accordions and so on are just different ways of presenting the same thing. In the weeks that followed, we started to identify use cases and requirements. We wanted a simpler way to work with these design patterns, switching between them for responsive design, and minimizing the code that needed to be written. We wanted to benefit from reduced code errors, and improved performance.

In usability terms we wanted to identify the common features of these design patterns so interaction could be more consistent. We also wanted something that could be dependably used by people using a setup the developer didn’t anticipate, like a screen reader or a custom keyboard and no mouse.

The result of our conversation is a proposal for some standard HTML that declares things as <panels> and <panelsets>, with a consistent set of DOM APIs. The proposed elements and attributes enable developers to describe the content to be presented, and separately choose the visual metaphor to be used. This separation makes it possible to switch between visual representations without changing the underlying structure or interaction, making things simpler for responsive design and more consistent for users.

It isn’t hard to write a specification, but it is hard to convince browser vendors to implement the proposal without a lot of theoretical discussion. It is easy to get things wrong at the proposal stage. In the real world developers might use things in unpredictable ways that cause problems, or the proposal might turn out not to meet the needs of most of the expected users. For example an early attempt at a standard way to use panels on the web was the HTML <frameset> element, which has now been almost entirely abandoned because they brought new unanticipated problems.

On the other hand, because agreeing on a standard and getting it implemented in browsers can take a long time, proposals are of little value to developers. It’s hard to comment on something until you’ve used it, and by the time it’s possible to use it it’s usually too late. To address this, Brian made prollyfill implementations, both as custom element definitions and Angular directives. Prollyfills are experimental implementations of proposed standards, and the hope is that developers will be able to use these implementations to provide useful feedback. If the proposal becomes a standard that is supported natively in browsers, the prollyfill can be reworked into a polyfill for browsers that don’t yet support it.

So, what’s the markup?

The basic model is a <panel> element, which is a container like div. Each panel should have a <paneltitle>, because even if it is not shown in some renderings, it will be useful for example to a screen reader user who cannot visually identify the panel.

<panel>
  <paneltitle>Today's weather</paneltitle>
  <p>Sunshine…</p>
</panel>

Multiple panel elements can be grouped together in a panelset element. This follows the convention for creating collections by placing child elements inside a parent container. This should help ensure developers find it intuitive, preventing simple mistakes.

<panelset>
  <panel>
    <paneltitle>Reposado</paneltitle>
    <p>Reposado tequila is…</p>
  </panel>

  <panel>
    <paneltitle>Blanco</paneltitle>
    <p>Blanco tequila is…</p>
  </panel>
</panelset>

To make a removable panel, the panel element can have a removable attribute. This gives the panel a button that can be used to remove the panel from the DOM.

<panel removable>
  <paneltitle>Today's weather</paneltitle>
  <p>Sunshine…</p>
</panel>

A panel can also have the expandable attribute applied. At present this indicates that a single panel is expanded, and if the panel is part of a panel set then all other panels in the set are collapsed. This feature is still under discussion because there is a use case for multiple panels to be expanded simultaneously, such as in an accordion.

You may have noted that a single expandable panel and its title seem to do the same thing as the proposal for <details> and <summary>, which did not have broad enough browser support to be included for HTML5 but is likely to be in a future version of HTML. If the panels proposal is accepted the <details> and <summary> elements could be considered a special case, or deprecated in favor of <panel> and <paneltitle>. We’ll only learn what happens as the future unfolds.

Finally there is the question of how to display a set of panels. A set of CSS pseudo-elements make it possible to provide different visual representations of the panelsetpreferreddisplay attribute enables developers to request a chosen visual metaphor that can be overridden by the browser. At the same time developers can use CSS media queries to switch the preferreddisplay attribute value at certain breakpoints, triggering proper responsive styling.

<panelset preferreddisplay="tabs">
  <panel>
    <paneltitle>Reposado</paneltitle>
    <p>Reposado tequila is…</p>
  </panel>

  <panel>
    <paneltitle>Blanco</paneltitle>
    <p>Blanco tequila is…</p>
  </panel>
</panelset>

So what happens now?

This is where you come in. We’ve put together a proposed specification, and we’ve tried to think of all of the angles. There are just four of us though, and there’s no way we’ll have covered everything. Even if we could, four people do not make a standard!

We need a lot of people to take a look at our proposal and kick its tires. Better still, we need developers and browser vendors to use the prollyfill prototypes, and let us know what works and what doesn’t. Above all we need everyone to ask questions and file issues for discussion, so we can get the specification to a viable state for implementation.

With thanks to Brian and Chaals, both of whom contributed ideas and words to this post.