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

+1 from me; 100% in favor of moving to the WICG.

A massive +1 from me, especially if this gets some momentum going.

+1 if we think it might help get traction.

+1 from me if it will help break through the current logjam

+1 please

I wrote the CSS element queries spec about a year ago, and I've done so much research and writing about element/container queries since then that was just thinking recently that I really need to go through this spec again to reword and clarify some of the terminology I used. Now I have some excellent motivation! 😁

Since then I've also found a simple way to describe element/container query behaviour as a JavaScript function.

Here's a demo showing how this function can be used to implement container queries with client-side JS in the browser.

And I've written down the most useful tests for this kind of technique.

Hopefully that sheds light on how the core of this idea works and which properties in the browser element queries rely on. If you were to expose an interface for this kind of functionality from CSS, it makes the most sense to do that as a new CSS at-rule that supplies:

• a CSS selector list
• test conditions
• a stylesheet (maybe with a placeholder to use inside selectors that matches tags that pass the test conditions, like $this)
• and optionally to allow authors to supply an 'event list' that limits the testing of the selector to specific events

If you want a great summary of where things are at now in the element/container queries scene, this article is fresh from last month: https://webdesign.tutsplus.com/articles/the-current-state-of-element-queries--cms-29690

Yeah, let's start the discussion!

@ausi @marcj @davatron5000 @filamentgroup @BoomTownROI @Snugug @tysonmatanich @d6u @walmartlabs @VinSpee @lemonmade
Feel free to join.

(☝️ All people who made a plugin / polyfill at one point.)

+1 from me. Keeping momentum on this has been difficult since we keep getting deferred by other specs. "Wait for CSS Containment. Wait for ResizeObserver. Don't waste time speculating on syntax."

+1 WICG, sounds good to me.

Step zero is to figure out what we're actually blocked on.

@tabatkins has a vision for how we move forward here. My conception of it is: ResizeObserver (✔️) + (✖️) → ergonomic, performant prolyfills (which, I mean, we kiiiiiind of have even now? even without custom MQs?) → widespread prolyfill adoption (we're at thousands of pages with prolyfills deployed, what counts as widespread?) → a spec and native implementations (✖️)

The twin blockers, in this plan/worldview, are custom media queries (which, like Dave says — waiting for stuff like this for years is super frustrating), and maybe (better?) prolyfills that more authors will feel comfortable using in production... or that implementors take more seriously as templates for future native implementations.

Something that might help push this forward: implementors and spec folks studying and giving feedback to the current prolyfills. How do those prollyfills succeed or fail at being platform compatible? Conversations like this one between @dbaron and @ausi feel invaluable and all too rare.

Since I got mentioned here 🙌:
What is exactly the goal here and how do you expect me to contribute? Did you guys look actually on real implementations first out there with hundred of thousands of installations before you start to create something own? Maybe compare usage-stats of current available implementation to understand what developers out there really want before creating a spec/product nobody needs.✌️

@marcj ☝️ In my mind that would be the exact reason of this discussion: look at what we have already, and decide on a syntax based on that, that's polyfillable and addresses concerns that stopped native approaches so far.

+1 for moving to WICG.

Regarding a vision to move forward, I strongly believe that CSS Conditions with Variables would be a great step forward for polyfills towards being performant and stable.

+1 yeah, why not 😆