Container queries

Every single browser maker has the same stance when it comes to features—they want to hear from developers at the coalface.

“Tell us what you want! We’re listening. We want to know which features to prioritise based on real-world feedback from developers like you.”

“How about container quer—”

“Not that.”

I don’t think it’s an exaggeration to say that literally every web developer I know would love to have container queries. If you’ve worked on any responsive project of any size, you’re bound to have bumped up against the problem of only being able to respond to viewport size, rather than the size of the containing element. Without container queries, our design systems can never be truly modular.

But there’s a divide growing between what our responsive designs need to do, and the tools CSS gives us to meet those needs. We’re making design decisions at smaller and smaller levels, but our code asks us to bind those decisions to a larger, often-irrelevant abstraction of a “page.”

But the message from browser makers has consistently been “it’s simply too hard.”

At the Frontend United conference in Athens a little while back, Jonathan gave a whole talk on the need for container queries. At the same event, Serg gave a talk on Houdini.

Now, as I understand it, Houdini is the CSS arm of the extensible web. Just as web components will allow us to create powerful new HTML without lobbying browser makers, Houdini will allow us to create powerful new CSS features without going cap-in-hand to standards bodies.

At this year’s CSS Day there were two Houdini talks. Tab gave a deep dive, and Philip talked specifically about Houdini as a breakthrough for polyfilling.

During the talks, you could send questions over Twitter that the speaker could be quizzed on afterwards. As Philip was talking, I began to tap out a question: “Could this be used to polyfill container queries?” My thumb was hovering over the tweet button at the very moment that Philip said in his talk, “This could be used to polyfill container queries.”

For that happen, browsers need to implement the layout API for Houdini. But I’m betting that browser makers will be far more receptive to calls to implement the layout API than calls for container queries directly.

Once we have that, there are two possible outcomes:

  1. We try to polyfill container queries and find out that the browser makers were right—it’s simply too hard. This certainty is itself a useful outcome.
  2. We successfully polyfill container queries, and then instead of asking browser makers to figure out implementation, we can hand it to them for standardisation.

But, as Eric Portis points out in his talk on container queries, Houdini is still a ways off (by the way, browser makers, that’s two different conference talks I’ve mentioned about container queries, just in case you were keeping track of how much developers want this).

Still, there are some CSS features that are Houdini-like in their extensibility. Custom properties feel like they could be wrangled to help with the container query problem. While it’s easy to think of custom properties as being like Sass variables, they’re much more powerful than that—the fact they can be a real-time bridge between JavaScript and CSS makes them scriptable. Alas, custom properties can’t be used in media queries but maybe some clever person can figure out a way to get the effect of container queries without a query-like syntax.

However it happens, I’d just love to see some movement on container queries. I’m not alone.

I know container queries would revolutionize my design practice, and better prepare responsive design for mobile, desktop, tablet—and whatever’s coming next.

Have you published a response to this? :

Responses

Wilto

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

# Posted by Wilto on Friday, December 15th, 2017 at 8:51pm

beep

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

# Posted by beep on Friday, December 15th, 2017 at 8:54pm

scottjehl

+1 if we think it might help get traction.

# Posted by scottjehl on Friday, December 15th, 2017 at 9:01pm

keithjgrant

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

# Posted by keithjgrant on Friday, December 15th, 2017 at 9:11pm

tomhodgins

+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

# Posted by tomhodgins on Friday, December 15th, 2017 at 9:55pm

ZeeCoder

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

# Posted by ZeeCoder on Friday, December 15th, 2017 at 10:05pm

davatron5000

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

eeeps

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

# Posted by eeeps on Saturday, December 16th, 2017 at 2:00am

marcj

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.✌️

# Posted by marcj on Saturday, December 16th, 2017 at 9:38am

ZeeCoder

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

# Posted by ZeeCoder on Saturday, December 16th, 2017 at 10:57am

ausi

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

# Posted by ausi on Saturday, December 16th, 2017 at 11:45am

d6u

+1 yeah, why not 😆

# Posted by d6u on Sunday, December 17th, 2017 at 4:54am

jehoshua02

I’m new here. But if I had a time machine, I’d stop media queries from being invented. 💯 On Dec 15, 2017 1:41 PM, “Tantek Çelik” wrote: > 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 > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , or mute > the thread > > . >

# Posted by jehoshua02 on Sunday, December 17th, 2017 at 6:06am

ZeeCoder

@tantek @Wilto So are we moving there? Is there a link we could start the discussion at? How is this gonna happen exactly? 🤔

# Posted by ZeeCoder on Wednesday, December 20th, 2017 at 12:57pm

tantek

Awesome, I’m not seeing any objections from anyone so let’s do this. @marcoscaceres (co-chair WICG) can you help us out with how to steps to transition an existing effort to WICG?

# Posted by tantek on Wednesday, December 20th, 2017 at 3:03pm

marcoscaceres

Happy to help. I can move it over. Once there, we will still need to lobby the right folks at various browser companies to get this moving. @tantek and I can help ping the right folks on the Moz side. However, let’s time this right so it doesn’t vanish during xmas.

ZeeCoder

Good point 👍 On 23 Dec 2017 09:25, “Marcos Cáceres” wrote: > Happy to help. I can move it over. Once there, we will still need to lobby > the right folks at various browser companies to get this moving. > > @tantek and I can help ping the right folks > on the Moz side. However, let’s time this right so it doesn’t vanish during > xmas. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . >

# Posted by ZeeCoder on Saturday, December 23rd, 2017 at 2:14pm

tomhodgins

This is great news, thanks @marcoscaceres! :D

# Posted by tomhodgins on Saturday, December 23rd, 2017 at 3:43pm

matchboxhero

I’m a little late to the party but I’m onboard, thanks for the invite. Let me know what I can do to help!

VinSpee

I am also late to the party but excited about this notion. I’d love to help in any way I can, code, docs, cat-herding, etc.

# Posted by VinSpee on Saturday, December 23rd, 2017 at 4:03pm

djlotus

Before I start trying to research who has implemented what polyfills and why, does anyone know if anyone has done this or begun doing this?

# Posted by djlotus on Wednesday, January 3rd, 2018 at 2:15pm

ZeeCoder

If you need a list of GitHub links, I have one.

# Posted by ZeeCoder on Wednesday, January 3rd, 2018 at 2:19pm

ZeeCoder

I’ve also been talking a lot with @tomhodgins too, since we couldn’t stop ourselves. I was waiting for the new forum to open before I presented that syntax we came up with. I think we should probably wait until the new forum opens to share our thoughts.

# Posted by ZeeCoder on Wednesday, January 3rd, 2018 at 2:21pm

djlotus

That would be great. Is this a list of available polyfills or a list of site authors who have implemented polyfills? I would be much more interested in the latter to get a feel for exactly what problems authors are solving in practice (not just in theory) and what made them choose the polyfills they chose. From my discussions with @tomhodgins and my lurking around other discussions it seems syntax is the main sticking point for most people and the main reason this discussion gets sidelined. I”ll let others fight over that since I personally don’t care (for the most part) what the syntax looks like. I’m more interested in making sure we can justify the underlying principal as to get solid buy-in from vendors.

# Posted by djlotus on Wednesday, January 3rd, 2018 at 2:22pm

ZeeCoder

Unfortunately I only have the former: - https://github.com/eqcss/eqcss - https://github.com/ausi/cq-prolyfill - https://github.com/marcj/css-element-queries - https://github.com/tysonmatanich/elementQuery - https://github.com/ZeeCoder/container-query I’m sure polyfill authors can post some sites that use their solutions. For example, mine is used by EventsTag for on-site products and some not-yet-public microsites. (The on-site products use web-based tech, running Chrome.) ☝️ That syntax is also very close to what we discussed with @tomhodgins

# Posted by ZeeCoder on Wednesday, January 3rd, 2018 at 2:30pm

tomhodgins

There is currently no shortage of element query plugins or syntaxes that can be used. I’ve also been maintaining a list of plugin authors over at: http://whoisworkingoncontainerqueries.com Here are some of the syntaxes and plugins I’ve created (all listed below except EQCSS were built in 2017) to help me use the idea of element queries as different project needs arose. Much of the functionality is similar between them, the biggest differences here are the location of the styles and how the selector, conditions, test, and styles are encoded into a syntax and read back by a plugin. Whatever syntax we create for CSS to handle this concept should have the power and flexibility to capture the functionality that these examples all have in common. Hopefully sharing these solutions sparks some creativity 😍 ## HTML-based Syntaxes ### Querious html css: css div.data-width { background: lime; } ### Skopein html css: css :self { background: lime; } ### reproCSS css ${demo.offsetWidth >= 500 ? ` #demo { background: lime; } ` : ''} ## CSS-based syntaxes ### QSS css div if width >= 500 { background: lime; } and other variations: css div @min 500 width { background: lime; } div @ >= 500 width { background: lime; } div if width min 500 { background: lime; } ### CSSplus/Selectory css div[test="this.offsetWidth >= 500"] { background: lime; } ### EQCSS css @element div and (min-width: 500px) { :self { background: lime; } } ## JS-based Syntaxes ### Container Query Mixin (Rule edition) js container('div', 'this.offsetWidth >= 500', '', ` background: lime; `) ### Container Query Mixin (Stylesheet edition) js containerQuery('div', el => el.offsetWidth >= 500, ` :self { background: lime; } `) ### Element Query JS-in-CSS Helper Function js element('div', {minWidth: 500}, ` :self { background: lime; } `) ## JSON-based Syntaxes ### Robserv js robserv.load([ { selector: 'div', test: el => el.offsetWidth > 500, stylesheet: ':self { background: lime; }' } ]) ### Parsed EQCSS js EQCSS.register([ { selector: "div", conditions: [{ measure: "min-width", value: "500", unit: "px" }], style: " :self { background: lime; } " } ])

# Posted by tomhodgins on Wednesday, January 3rd, 2018 at 3:24pm

ZeeCoder

So who’s in charge for starting the discussion at the WICG? 🤔 I’m eager to discuss what functionality should even be considered for implementation, syntaxes and potential barriers for browser vendors, as well as experiences of plugin authors. I do think that such a discussion would have to be very focused though, so I’m resisting the urge to spam my thoughts until we’re set on how it’s gonna actually go down. ping @tantek @marcoscaceres

# Posted by ZeeCoder on Monday, January 15th, 2018 at 1:25am

marcoscaceres

Ok, back from vacation… let’s start by moving this over :) Now, we need to figure out who will edit and participate in the work. Can folks here me know who is going to be involved? I need a list of collaborators. Should we set up a Hangout session do discuss the state of things and find a “champion” to drive this work?

tomhodgins

Welcome back @marcoscaceres! You can count me in for sure :D

# Posted by tomhodgins on Tuesday, January 16th, 2018 at 12:30am

ZeeCoder

Ah sorry didn’t mean to bug you during your vacation. 😅 I’m in ofc!

# Posted by ZeeCoder on Tuesday, January 16th, 2018 at 12:30am

2 Bookmarks

# Bookmarked by Pelle Wessman on Thursday, July 20th, 2017 at 1:05pm

# Thursday, July 20th, 2017 at 5:30pm