This specification extension defines elements and attributes for constructing a panel or collection of panels based on a single interaction paradigm.
Using custom elements, a collection of functional prototypes is available. All DOM methods are under-scored to preserve forwards compatibility.
Work on this extension is being done on Github. Please share comments and feedback using the Github issue tracker.
The concept of a content panel originates in print media and has carried over into digital media. The transition to digital media brought about the ability to interact with collections of panels, and over time a number of visual metaphors for this interaction have emerged. Tabs, accordions, decks and carousels are all design patterns based on interactions with sets of content panels.
The history of interface design shows that each of these design patterns has evolved independently, despite their similarities. The WAI-ARIA Authoring Practices Guide for example, describes a set of tabs and an accordion widget in identical terms except for visual orientation.
With the growing number of screen sizes and the advent of responsive design, these visual metaphors may no longer be constant. A set of tabs may be the logical choice for displaying content on a wide-screen, but the same content may be more intuitively displayed as an accordion or a deck on a narrow-screen. However, the interaction model and semantic information for each of these design patterns remains the same, regardless of the visual representation.
This extension defines a set of HTML elements and attributes for representing collections of content panels with appropriate semantics and interactions. The task of adopting a particular visual metaphor is left to CSS.
All authoring guidelines, diagrams, examples, notes, and sections marked "informative" in this specification are informational. Everything else in this specification is "normative" as described in [[!qaframe-spec]]. The key words "must", "should", "should not" and "may" in this specification are to be interpreted as described in [[!RFC2119]].
The Interface Definition Language (IDL) fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [[!WEBIDL]]
This document uses the terms accessible and accessibility in the sense of ensuring people with disabilities can use the Web.
The panels specification describes a number of elements and attributes that give authors the ability to present panels or collections of panels in a semantically consistent way.
panel element represents a chunk of content with a header that includes a visible title (
paneltitle element). A
panel element may be used on its own, or with other
panel elements as part of a collection (
Github issue 16
It isn't presently possible to imperitively create a panel element.
Github issue 9
Should it be possible to script a panel element to become either removable or expandable?
Github issue 32
Is panel-title a required child of panel element?
Github issue 33
why not re-use open attribute instead of expandable?
paneltitle element represents the visible title of a panel (
panel element). A
paneltitle is the basic component of the panel header.
panelset element represents a collection of panels (
panel elements). A
panelset may contain one or more
panelset element manages the selection of its child
panel elements. In other words, when
panel elements are children of a
panelset element, they are automatically collapsible.
panel element within a
panelset element should be expanded by default. Any subsequent claims of expansion trump the original claim.
Github issue 5
Should the panelset element have selectedIndex?
Github issue 25
If HTML authors are encouraged to follow this separation, it inevitably begs the question about how CSS authors can correctly manage which type of display the element takes on in which conditions. This is currently "up in the air". One approach, prollyfilled here, is to use an attribute.
Github issue 19
Different visual metaphors have different selection (expansion) patterns. How can this be managed if the panelset element is predicated on a single selection model?
Github issue 28
When an AT is enabled on a touch device, only basic events are fired (mouse events, and in some circumstances blur/focus events). Is this something to consider?
The removable attribute is a Boolean attribute that indicates that a panel element can be removed from the user interface. When a panel element is dismissed from the user interface, it is removed from the DOM.
When the removable attribute is present, a mechanism to dismiss the panel is included in the panel element header.
expandable attribute indicates the expanded or collapsed state of a
expandable attribute is present, the
paneltitle element becomes a control that allows the
panel element to be toggled between an expanded or collapsed state.
expandable attribute is present and has no value, the panel is in a collapsed state. If the expandable attribute is not present, or is set to
true, the panel is in an expanded state.
Github issue 20
When you follow a link to a panel does it automatically expand?
prefereddisplay attribute determines the initial visual representation of a
panelset element containing one or more
This section is non-normative. [section is full of conformance requirements ??]
paneltitle elements are used, the user agent should expose a user interface to the user. This user interface should include a visible title, and may optionally include an author provided icon or indicator of expandable state.
If the removable attribute is present, the user interface should include a control for dismissing the panel element from the user interface. The control should be focusable and have an accessible name.
If the expandable attribute is present, the paneltitle should become a control for toggling the panel between an expanded or collapsed state. The control must be focusable.
Github issue 27
Should we include recommended/suggested interaction models here?
This section is non-normative.