-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.
+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.
-
Status of This Document
+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).
-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.
+
Proposed Solutions
-
Use Case
+
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-widthmedia query to reflow content.
@@ -68,19 +78,24 @@ The module in this new sidebar context will never need to reflow to the wider la
A stylesheet heatmap showing added redundancy and rewriting of existing styles required to accommodate 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.
+
Requirements
-
-
- A wireframe illustrating how a single module addresses all potential layout contexts fig. 2 and fig. 4, given a native “element queries” solution
-
+
The use cases give rise to the following requirements:
-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
-
+
To the extent possible under law, the editors have waived all copyright
and related or neighboring rights to this work.
-In addition, as of 30 May 2014,
+In addition, as of 20 November 2014,
the editors have made this specification available under the
Open Web Foundation Agreement Version 1.0,
which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0.
@@ -569,41 +585,49 @@
-
Abstract
-
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!
-
+
Abstract
+
This document captures the use cases and requirements for standardizing a solution for element queries. The use cases and requirements were gathered with consultation with the HTML Working Group and WHATWG participants, RICG group members, and the general public.
+
+Found a bug or typo? Please file an issue on GitHub!
+
+
+
+
Status of this document
+
+This is an unofficial draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.
+
+
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.
-
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.
+
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.
+<<<<<<< HEAD
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.
+=======
+
This document aims to present some of the use cases that an element query soution would address. The goal is to demonstrate a need for a method of allowing content 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.
+>>>>>>> Removed proposal-esque text.
-
2 Status of This Document
+
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).
-
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.
+
2. Proposed Solutions
-
3 Use Case
+
3. Use Cases
-Figure 1 is an example of a relatively simple and fully self-contained module’s layout, using only a single min-widthmedia query to reflow content.
+
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-widthmedia query to reflow content.
@@ -635,28 +659,38 @@
3
- A stylesheet heatmap showing added redundancy and rewriting of existing styles required to accomodate the layout variation in fig. 4
+ A stylesheet heatmap showing added redundancy and rewriting of existing styles required to accommodate the layout variation in fig. 4
+<<<<<<< HEAD
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.
+=======
+
4. Requirements
+>>>>>>> Removed proposal-esque text.
-
-
- A wireframe illustrating how a single module addresses all potential layout contexts fig. 2 and fig. 4, given a native “element queries” solution
-
+
The use cases give rise to the following requirements:
-
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
-
+
You can also see all closed issues relating to this document.
+
+
7. Acknowledgements
A complete list of participants of the Responsive Images Community Group is available at the W3C Community Group Website.
-
+
+
Conformance
@@ -669,7 +703,7 @@
All of the text of this specification is normative
- except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
+ except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
@@ -683,28 +717,9 @@