diff --git a/index.bs b/index.bs index d956bcc..e12f6ee 100644 --- a/index.bs +++ b/index.bs @@ -7,8 +7,8 @@ Shortname: eq-usecases Level: 1 Editor: Mat Marquis, RICG, http://responsiveimages.org Editor: Scott Jehl, Filament Group, http://filamentgroup.com/ -Abstract: This document captures the use cases and requirements for standardizing a solution for “element queries.” -Abstract: 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. +Abstract: Found a bug or typo? Please file an issue on GitHub! !Version History: Commit History !Participate: IRC: #respimg on W3C's IRC !Participate: GitHub @@ -21,17 +21,27 @@ Abstract: Found a bug, typo, or issue? Please file a +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. + +If you wish to make comments regarding this document, please send them to public-respimg@w3.org (subscribe, archives). All comments are welcome. + +

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. +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-width media 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. +
    +
  1. +
  2. +
-
- -
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
-
+

Open issues

+ +We are tracking open issues on Github. Please help us close them! + +

Change history

+ +A complete history of changes is available on Github. + +You can also see all closed issues relating to this document.

Acknowledgements

diff --git a/index.html b/index.html index 97a2151..abe3f39 100644 --- a/index.html +++ b/index.html @@ -56,7 +56,7 @@ p.copyright { font-size: small; } p.copyright small { font-size: small; } -pre { margin: 1em 0 1em 2em; } +pre { margin: 1em 0 1em 2em; overflow: auto; } pre, code, .idl-code { font-size: .9em; font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace; @@ -64,6 +64,7 @@ dt dfn code { font-size: inherit; } dfn { font-weight: bolder; } +dfn var { font-style: normal; } s, del {text-decoration: line-through; color: red; } u, ins {text-decoration: underline; background: #bfa; } @@ -79,6 +80,8 @@ dd { margin: 0 0 1em 2em; } ul, ol { margin-left: 0; padding-left: 2em; } li { margin: 0.25em 2em 0.5em 0; padding-left: 0; } +[data-md] > :first-child { margin-top: 0; } +[data-md] > :last-child { margin-bottom: 0; } td.pre { white-space: pre-wrap; @@ -537,6 +540,15 @@ border-right-style: solid; } + + + +
-

- Responsive Images Community Group +

+ Responsive Images Community Group + + + W3C

Use Cases and Requirements for Element Queries

-

Editor’s Draft, - 30 May 2014

-
This version:
http://responsiveimagescg.github.io/eq-usecases/
Editor’s Draft:
http://responsiveimagescg.github.io/eq-usecases/
Test Suite:
None Yet
Editors: -
Mat Marquis (Filament Group)
Scott Jehl (Filament Group)
Version History:
Commit History
Participate:
IRC: #respimg on W3C’s IRC
GitHub
+

Editor’s Draft, + 20 November 2014

+
This version:
http://responsiveimagescg.github.io/eq-usecases/
Editors:
Scott Jehl (Filament Group)
Version History:
Commit History
Participate:
IRC: #respimg on W3C’s IRC
GitHub
-

-

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. + +

If you wish to make comments regarding this document, please send them to public-respimg@w3.org (subscribe, archives). All comments are welcome.

+
-

Table of Contents

-
+

Table of Contents

+
+
+

1. Introduction

-

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 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-width media 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-width media 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.

+
    +
  1. +
  2. +
-
- -
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
-
+

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.

-

4 Acknowledgements

+

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 @@

class="note", like this: -

+

Note, this is an informative note. -

-References

- -

-Normative References

-
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. URL: http://www.ietf.org/rfc/rfc2119.txt
- -

-Informative References

-
- -

-Index

-
    -
- -

-Property index

-

No properties defined.

- +

References

Normative References

[rfc2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt

Index

  • element query, 1
  • requirements, 4
  • solution, 1
  • use cases, 3