per @marcoscaceres comment in #44

So, we need a single-breakpoint module dealie that breaks in especially visible ways when dropped into an inappropriate context. Once we have these layouts sorted, I’ll replace the Layout A/B placeholders in the layout wireframes with these (see #1). I’m working on a couple of things for this, but if anyone wants to take a stab at it here’s the template:

I'm thinking we can use this issue as a grab bag for examples of in-the-wild container query use.

Don't worry about whether it's a New Use Case, or worth posting — just post!

I was hoping to layout the various hacks that can be used for the polyfill, and open up a discussion of what is and is not acceptable.

Matching:

• Object Element: Using matchMedia on a nested object element within the container.
• window.resize: On resize do a check on each container.

Configuration:

• document.styleSheets: Loop through each rule and check if it has EQ information
• Element attributes: Setting an element's EQ(s) via an attribute
• Parsing Text: Manually parsing CSS text for the new syntax, which would be currently invalid css
• CSS properties that accept text: Using the content property

What other methods could we add to this? And what methods can we absolutely say "no that's just too hacky".

This topic is created as a place for us to discuss and determine the scope of the queries and the styles they can apply.

Things that need to be decided:

• Is there a 'container' concept?
• What would the limitations of a 'cointaner' concept be?
• Are certain properties/abilities blacklisted from affecting their parent?
• Does/should styles in the element query be able to affect global styling?
• How can CSS authors refer to the element they are querying as a selector?
• Are edge cases like + *, ~ *, and :has() out of scope?
• anything else…

Hopefully by the time we reach the end of this discussion we'll know:

• will our solution have a 'container' concept
• what the boundaries of the contained styles are
• how you should select and refer to the element you're querying

An excellent workflow suggestion was raised by @marcoscaceres on #64:

Two options: keep iterating and using the Previews at the top of this pull request to share and review the changes, or merge early/often and iterate.

I'm personally a fan of the former (keep hacking on a single PR), but the other way works fine too.

Generally, most of us in Slack (reminder: you can join us there!) default to the “merge PRs frequently, and iterate” workflow on collaborative projects. But given that (so far) our PRs have been opening at a fairly low volume, I can see the benefits of really honing a PR before merge.

This issue isn’t a blocker, and may not directly impact our workflow. But I am curious to know if anyone has any thoughts on the two models. Any preferences out there?

Please copy/paste this file to the root of the repo:
https://github.com/WICG/permissions-request/blob/master/.pr-preview.json

It will make reviewing pull requests much easier, as it generates the spec for us... better than looking at ugly BS-HTMLs :)

I propose element queries should be based not on the parent width, but on the element width. The element might be constrained in some cases to a fixed width while the parent may be larger.

I would modify the document as follows:

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 the element itself. For the purposes of this example, we would be then be able to scope out modules’ layouts to the size of the module itself.

I haven't read any farther than this yet. There may be other modifications necessary to keep everything in harmony.

I'm not sure where else to discuss this: it seems I'll do a talk on container queries and how they work with react components.

If anyone has ideas on what I should not forget to mention, feel free to post a comment here.
I'll definitely talk about existing plugins, and about the movement at the WICG for example.

I believe there is a typo in there. Search for "then below thatm two across." s/thatm/that/

(Just opening a master bug to file against our v1 milestone.)

Following this discussion, document a use case with a height-based CQ. A banner with min-height specified in vh units, with three child elements.

If the banner element is beneath a certain height, the three elements should appear inline. If it is above a certain height, they can stack various ways.

@davatron5000 is cataloging the CSS properties that may trigger race conditions for element queries. I’ve put them into a list to share with you:

https://gist.github.com/jonathantneal/5996a3e9b33d7a6afa5d

In a lot of cases, container queries are a developer-convinence feature.

In other words — you could write Media Queries; there's a deterministic relationship between viewport size and component state — but Container Queries would be much more compact, DRY, understandable, explainable, & maintainable.

I sort of hesitate to suggest it, but if the inherent layout performance penalties involved in evaluating CQs are too heavy at runtime, perhaps they could be better implemented in-front of some kind of pre-processing tool? Which would convert all of your tidy CQs into MQ spaghetti, for deployment.

Open issue / request / call as @marcoscaceres did in issue #44
Currently @beep and @eeeps have volunteered, on the condition that they can reach out for help and mentorship (which I, as well as @marcoscaceres and other WICG co-chairs are happen to do).

Like this, but for Container Queries.

@andykirk, who wrote an excellent article outlining a bunch of use cases and current-workaround-techniques, has agreed to give this a go, soonish (I’ll assign him as soon as he accepts the collaborator invite).

So, there are two sides to this: the CSS side of things (“what do the element queries look like”) and the element side of things (“how do we define an element as having viewport-like qualities”).

We can’t treat every element as having viewport-ish behavior, or we end up with a fractal nightmare of reevaluation and potential infinite loops: an element sets a child element to width: 200% which cascades back upward and changes a series of parent elements each with potential element queries attached, and one of those causes the width: 200% EQ to no longer apply, and so on unto infinity. There have been a few things up for discussion: a specific “treat as a viewport” element or attribute among them.

http://dev.w3.org/csswg/css-containment/#containment seems like something we should be keeping an eye on, since it deals with special-casing elements independent of the rest of the page, though in a very different way.

The “things” that are changing in response to what we’ve settled on (for now) calling “container queries” need one name.

The existing use case uses “module” throughout. In keeping with the term “container query”, @andykirk’s recent limitations section uses “container” consistently, which seems sensible. In a couple of use cases that I’ve been writing up, I’ve found myself using “component” (oops), which I like – but I'd rather everything be consistent.

I like “module” and “component” because they avoid hinting at any technical solution (whereas “container” is a bit DOM-y).

I especially like “component” because it aligns with what I think people mean when they talk about Web/React/Vue/Angular “components”: portable, reusable, logical, cohesive things on a webpage.

Of course there are also BEM “blocks” and OOCSS “objects”, which refer to similar (identical?) concepts. For me, “block” has some specific connotations in CSS that I’m not sure we want, and “object” is, well, overloaded.

Those are my loosely held thoughts. It’s more important to pick one name than pick the perfect name; we’ve got two in the document now and I caught myself adding a third. Any thoughts?

Be great to list the newly minted slack channel in the README and possibly in the CONTRIBUTING.md file... the same applies to the other repo.

There is a "be" too much on https://github.com/ResponsiveImagesCG/eq-usecases/blob/gh-pages/index.html#L641

In para 2, sentence 2 of the Intro:

"to facilitate the constuction of layouts"

should be

"to facilitate the construction of layouts"

In para 2, sentence 2 of the Intro:

"a method of allowing content respond to its container’s dimensions"

should be

"a method of allowing content to respond to its container’s dimensions"

I’m currently working on a redesign of my website and have been using viewport units for larger headlines. Viewport units are perfect for creating fluid-sized text without having to resort to media queries to specify a font size based on those. (That being said, we do need to use media queries at present to “limit” the font size to a minimum and maximum, otherwise it will become too small on very small viewports, or too big on bigger widths.)

On my website, I have elements representing a calendar entry (basically just a rectangular shape with a date and some text in it)(see attached image below). I want the date to be sized proportional to the entry's width instead of the viewport width because:

1. Using viewport width would cause the date's font size to be too small on smaller viewports, even though the entry isn't really small. The text needs to be bigger and viewport units don't give me that without resorting to media queries.
2. Using viewport units would cause the date's size to be TOO big when on desktop. For example, say the maximum width of the entry is around 350px—even on wider screens. Using viewport units, the size would be to big to fit inside the entry. I would have to explicitly set the sizes using media queries again to make it work—which negates the whole idea of fluid text using these units.

Attached is a screenshot of the current state of these “calendar entries”.

The date's size needs to be changed using media queries for it to work as needed. If I were able to set it relative to its container's size, it would resize as much as needed and stop at a certain limit when the element's width doesn't increase anymore.

I realize this may be one of those "circular/infinite loop" situations since the element's width is based on its content's width, but it does fall under the element queries use cases nonetheless.

Would it be easy or worth it to add anchor tags throughout the document to link to individual paragraphs in issues and things?

There’s a color-coding and an A/B code for which layout applies where, and it is just a lot of stuff going on. The actual write-up might help a bit, but we might be better off putting the actual Layout A and Layout B in the color coded containers—maybe at a lowered opacity, so there doesn’t seem obnoxiously busy.

As discussed, it'd probably align expectations better if we rename the whole thing "Container Queries" (or equiv) rather than "Element Queries" (since we cannot query on based on any arbitrary element in the page).

The main use-case in the doc, right now, is modular components that can appear in a variety of different contexts. It’s a real drag to write and maintain different media queries for each potential context.

If elements are user-resizable – e.g., textarea by default or anything with a CSS resize != none – there’s no way to work out an element’s size from the size of the viewport; media queries become useless.

A couple of use cases that come to mind:

• a resizable textarea that adjusts its typography in response to its size, in order to keep line lengths nice and readable, like https://ia.net/topics/bringing-responsiveness-the-app-world/
• user-arrangeable tool palettes (e.g. a color picker that goes from HSV sliders when short, to an HSV wheel when tall)

In para 2, sentence 2 of http://responsiveimagescg.github.io/eq-usecases/#intro

"The goal is to demonstate a need"

should be

"The goal is to demonstrate a need"

I want to be sure that EQs evaluate per element. I can have two elements, matching the same selector, but not necessarily the EQ at the same time.

I do this in Reusables Breakpoints.

Element width, is an obvious one.

Height, sure.

Aspect ratio? Why not! But what about arbitrary CSS properties, or, say, lines of text or number of children?

There are use cases for all of these things. What's practical to require from the start, and how should the door be kept open for queries of the future?

Hi,

I find it a shame that not much is happening in this area. A while back I wrote this:

https://www.sitepoint.com/responsive-css-patterns-without-media-queries/

It didn't elicit much response (though it was referenced by Ethan Marcotte: https://ethanmarcotte.com/wrote/on-container-queries/), but I thought I'd post it here for prosterity.

Personally, I can't wait for Container Queries to be a reality, and though I understand there are some very complex issues involved, I wanted to add my voice to the "we need this" group.

Cheers,
Andy

As suggested by https://twitter.com/elrond25/status/941743760773283840 do people think it would help, make no difference, or hurt to move Container Queries to the WICG to restart/retry discussions to get more traction and momentum?
@Wilto @beep @adactio @jensimmons @keithjgrant @rachelandrew @innovati @dbaron and please @-more folks who have contributed / shown interest in helping make Container Queries happen.

Some recent-ish blog posts for background/context:

• https://adactio.com/journal/12585
• https://ethanmarcotte.com/wrote/on-container-queries/
• https://ethanmarcotte.com/wrote/a-bit-more-on-container-queries/

Draft proposal being updated:

• https://github.com/tomhodgins/element-queries-spec

link to https://responsiveimagescg.github.io/cq-usecases/ is 404

So, the primary use case—which may be the only use case, really—is pretty easy to explain in broad terms. I’d love to see some community-contributed specific use cases, though: links to things you’ve worked on that would’ve been much less painful given an “element query” solution, uses that aren’t covered by the stuff we’re illustrating so far, and so on. No formalities needed—if you have a link to a live example or a Codepen/jsbin/jsfiddle, a write-up, a blog post you’ve read on the subject, whatever: fire away in the comments.

https://daverupert.com/2018/04/pitfalls-of-card-uis/#responsive-collapsing
https://twitter.com/davatron5000/status/982351699367968770
https://codepen.io/davatron5000/pen/zWMrNq?editors=1100

Need to think through whether this is different enough from the existing use case for inclusion in the doc, but given that we still only have one of ’em in there, I’m trying to capture any potential new ones I see out there...

It should, at the very least, tell folks that they need to sign up for the WICG first.

In the narrowest layout (see screenshot below), the boxes should have a red background, not a blue one.

Also, consider using 3 different colors (A, B, C). It took me a while to figure out the relations because I wasn't sure which boxes are A and which are B :)

All existing experimental prollyfills are susceptible to some form of FoUC/layout jank.

As elements are laid-out, and then queried asynchronously[1], before being, possibly, re-laid-out, re-queried, &etc — it’s hard (though maybe not impossible?) to implement CQs in a way that doesn't take a few paints to settle down.

This is why Shopify abandoned their CQ solution: https://twitter.com/dfmcphee/status/870458614842105856

Personally, container queries taking effect "a frame later or so"[2] on window resizes bugs me very little. But jank on the initial load bugs me very much.

Are there reasonable, specific requirements we can set up around FoUC/layout jank?

[1]: for the importance of async querying as an essential part of any CQ solution (and not just an unfortunate characteristic of temporary prolyfills), see https://twitter.com/gregwhitworth/status/850129597844701184
[2]: https://lists.w3.org/Archives/Public/public-respimg/2016Sep/0004.html

Getting a list of articles on the subject going.

• http://filamentgroup.com/lab/element-query-workarounds.html
• http://www.jonathantneal.com/blog/thoughts-on-media-queries-for-elements/
• http://www.xanthir.com/b4PR0
• http://www.xanthir.com/b4VG0

Keep ’em coming.

This is a non-normative document, so shouldn't have a conformance section.

Everything that I read from people who understand the mechanics of layout leads me to believe that container queries are going to be necessarily more expensive than media queries, and potentially much more expensive.

Here’s a choice example from @dbaron (emphasis mine):

If you have an algorithm that's fundamentally two-pass, then you either (1) need to re-layout everything back to the first pass state and then re-layout everything again back to the second pass state, or (2) maintain separate data structures of the first pass and second pass states. For nesting of elements that use container queries, (1) would yield an exponential cost in time and (2) would yield an exponential cost in memory usage; I don't think either is likely to be acceptable as a performance/memory characteristic of the Web platform.

We should at least mention performance in the document. However, as I said in #7, I am wary of putting any particulars on this. My feeling is, any performance requirement we include should be from users’ or authors’ perspectives, not implementers’. We should write about the consequences of performance, – rather than writing from a hardcore Computer Science perspective, with an understanding of the problem from the inside, out (as @dbaron does above).

Ideas? Volunteers?

per @marcoscaceres comment in #44

There may be times I want to execute some javascript when EQ matches or unmatches.

One definite use case for this I've encountered so far is with rendering ads in responsive designs. I don't want to inflate impressions with ads that aren't being displayed. So I want to defer rendering of the ads until they are going to be displayed in a responsive design.

Let's say I want to render ads in a column layout between every two rows. But my layout goes from one column to two column to three column. Meaning the number of items between each ads changes with the columns. If I can hook into the EQs that are responsible for the columns, I can execute javascript that renders the appropriate ads.

Also very common is displaying ads of different dimensions at different screen sizes. If I can hook into EQs that are responsible for changing layout, I can render the ads of appropriate size.

I'm doing this sort of thing with Reusables Breakpoints

Just like it says on the tin.

I’ve been working on illustrations as a weird sort of outline but if anyone wants to start drafting some general-purpose copy on the main idea of element queries, it would be hugely helpful.

Given some recent activity in the container-queries repo (e.g., WICG/container-queries#6; WICG/container-queries#7), a question: how does the RICG evaluate the quality of a proposed implementation?

I think it’d be helpful to spell out what the success/fail criteria are for proposed solutions: e.g., does it address circularity concerns; does the syntax meet certain architectural criteria; &c.

I'm wondering if the use cases document needs a "Requirements" section, similar to the one in the responsive images use cases doc.

We need to find a way of having TravisCI autogenerating the spec. We shouldn't be seeing the generated version as part of a pull request. If generation fails, then it means something is wrong with the spec.

Maybe there is some guidance over in the BikeShed repo about this? Let's ping Tab if we don't find anything there.

Eventually, I want to be able to do something like:

<picture>
  <source container="(width > 500px)" srcset="original.jpg" />
  <img src="cropped.jpg" />
</picture>

Dunno if it’s worth stating this use case in this document, or whether we should just figure out container-queries-in-CSS first, and then figure out how to plug them into HTML later.

I'm a bit bothered to see a solution proposal in the use cases document. The use cases document should really only make recommendations about what the requirements are, but not propose a solution itself. What is could do is instead point to proposed solutions - and discuss the pros and cons of those.

I came up with Localised CSS before I found out about the Element Query movement. Glad to hear that there's some progress on this!

In the meantime, Localised CSS could be used as a polyfill for Element Queries. This blog post justifies some of the design decisions for the API.

Any feedback would be appreciated.