Given a complex responsive layout, developers often require a more granular level of control over how the contents of an individual module will respond relative to the size of their containing context rather than the viewport size. Styling based on viewport size alone is prohibitive to the goal of creating modular, independent components, often requiring redundant CSS, complex exception cases, and workarounds. This problem compounds itself depending on how dramatically a module adapts at each of its breakpoints.
For the purposes of this document, an element query refers not to a specific syntax or proposed method of addressing the use cases that follow, but a method of controlling styling based on the size of a containing element.
This document aims to present some of the use cases that an “element query” syntax would solve, in allowing authors to define layouts within an individual module on the basis of the size of the module itself rather than the viewport. The goal is to demonstrate a need for a method of allowing content to respond to its container’s dimensions (as opposed to the overall viewport size), to facilitate the construction of layouts comprised of many modular, independent HTML components with a minimum of duplicated CSS and overrides specific to the modules’ parent containers.
In formulating the requirements, this document tries to be neutral—it is not predicated on any solution. The document only tries to describe the use cases and what the RICG understands, from practice, would be needed to address the use cases in the form of requirements. The RICG expects that a technical specification can be created to formally address each or all of the requirements (i.e., the solution).
2. Proposed Solutions
3. Use Cases
The following use cases represent common usage scenarios:
Figure 1 is an example of a relatively simple and fully self-contained module’s layout, using only a single
min-width media query to reflow content.
In our example site’s homepage layout this module can occupy containing elements of varying widths, governed by multiple breakpoints. In small viewports, we’ll be using a linear layout where each of our five module occupies the full viewport—this layout is covered by the base styles outside of our media query. At higher breakpoints, these modules will be displayed side-by-side: three across, then below that two across. The three-across layout will be covered by the global styles within our viewport-based media query. Parent-specific overrides will need to be written for the two-across layout, as these modules will need to shift to their wide-format at a smaller viewport size than the ones above them.
In order to accomplish this we’ll need to duplicate all of this module’s “wide layout” styles into a second viewport-based media query—set to apply at a smaller min-width than the global breakpoint styles—with all of our styles scoped to a parent container. This now means that any future edits or bug fixes to the wide-format layout styles will need to be made in multiple places, and this maintenance cost increases exponentially with each module-level breakpoint required.
Similarly, introducing a new context unlike the previous two—shown in figure 4 with the introduction of a “sidebar” on an interior page layout—means duplicating or overriding all of our module’s media queries yet again.
The module in this new sidebar context will never need to reflow to the wider layout, and as such we’re left with two options: scoping all of our modules—with the exception of the two-across layout—to a parent class, or introducing a new media query that overrides all of our wide-layout styles based on the sidebar’s parent class. Despite the relative simplicity of our module and our overall page layouts, we’re left with a bloated and difficult to maintain stylesheet.
The use cases give rise to the following requirements:
5. Open issues
We are tracking open issues on Github. Please help us close them!
6. Change history
A complete history of changes is available on Github.
You can also see all closed issues relating to this document.
A complete list of participants of the Responsive Images Community Group is available at the W3C Community Group Website.