Responsive Images Community Group

Use Cases and Requirements for Element Queries

Editor’s Draft, 30 May 2014

This version:
Editor’s Draft:
Test Suite:
None Yet
Mat Marquis (Filament Group)
Scott Jehl (Filament Group)
Version History:
Commit History
IRC: #respimg on W3C’s IRC


This document captures the use cases and requirements for standardizing a solution for “element queries.”

Found a bug, typo, or issue? Please file a bug on GitHub!

Table of Contents

1 Introduction

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 parent container rather than the viewport size. This is prohibitive to the goal of creating modular, independent components, often requiring a number of redundant CSS, complex exception cases, and workarounds, and the problem compounds itself depending on how dramatically a module adapts at each of its breakpoints.

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.

2 Status of This Document

This document reflects the efforts of members from the Responsive Images Community Group (RICG), and with ongoing feedback from the designer/developer community via blog posts, informal polls, and other social media sources. The RICG’s goal for this document is to make sure that author requirements for element queries have been documented.

3 Use Case

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.
An example of a self-contained module that requires a single breakpoint.

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.

Some of the contexts in which the module in fig. 1 might appear.

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.

A stylesheet heatmap showing the redundant styles required to accomodate the layout variations in fig. 2

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.

A wireframe introducing a new context for the modules in fig. 1, where no breakpoint should apply

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.

A stylesheet heatmap showing added redundancy and rewriting of existing styles required to accomodate the layout variation in fig. 4

What this document proposes is the addition of an “element query” syntax, allowing breakpoints to be applied based on the width of a parent container. For the purposes of this example, we would then be able to scope out modules’ layouts to the size of the module itself.

A wireframe illustrating how a single module addresses all potential layout contexts fig. 2 and fig. 4, given a native “element queries” solution

In doing so, we’re able to assemble a layout without parent-specific media queries, styles, or overrides.

A stylesheet heatmap showing a lack of redundancy when accomodating the layout variations in fig. 2 and fig. 4, given a native “element queries” solution

4 Acknowledgements

A complete list of participants of the Responsive Images Community Group is available at the W3C Community Group Website.


Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.


Normative References

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. URL:

Informative References


Property index

No properties defined.