Element queries (or “container queries” if you must) continue to make their way into conversations amongst responsive web design makers, but their inclusion into any spec and the present landscape is unclear. In this article we’ll discuss what element queries are and where community consensus currently finds itself amongst developers and standards working groups.
What Are Element Queries?
Element queries allow elements to “react” to their own constraints regardless of the constraints of screen size. This is the most significant detail one must understand. Media queries as we know them are 100% for responsive layout, but responsive layout isn’t 100% @media queries. Modules, components, interface elements will always grow and shrink with the screen, but never react on their own, which is why @media isn’t the entire solution to our issues.
Take a look at this rough demo of element queries using eqcss:
The Frontline
Many people seeking solutions for element-based breakpoints began implementing CSS-in-JS using frameworks such as React. While progress has been made in other areas, this fractured the solutions developers were creating from general-use solutions for CSS or JavaScript into multiple framework-specific libraries. While results vary, the core features these tools achieve are often very similar. In the future, a standardization of these assorted techniques could solidify an approach to this type of responsive design to be applied to any website, or any tool.
During my discussions on this topic with Tommy Hodgins (an advocate of element queries and creator of eqcss) it seems folks are still aware of both “element queries” and the separate concept of “container queries”. The consensus appears to be split into a few different areas:
Here is another example where I can change the CSS based on the video’s width. Totally unrelated to viewport size. pic.twitter.com/O6lbDBJvFf
— Wes Bos 🔥 (@wesbos) October 6, 2017
I want Houdini. I think it’ll let us create concepts that browsers can use to go native.
— Snook (@snookca) October 6, 2017
Wanna make a splash in the web dev world? Be the one who makes a working implementation of container queries with Houdini. 🤹🏼♂️
— Chris Coyier (@chriscoyier) October 10, 2017
So what’s on the wishlist for developers?
- Create a Resize Observer and study the benefit of giving developers a better primitive to build width-based breakpoints from. This is the fundamental piece we need using JavaScript to do element queries efficiently. The unfortunate news is that Resize Observer isn’t ready, but the community of its creators are hard at work making that a reality. You can read the public facing spec if you’d like to dive in further.
- Develop Houdini into a working model and showcase it as a perfect use-case towards our needs. At the present time the CSS Working Group is, in fact, focusing on Houdini.
- Provide further power to developers using the APIs set by the CSS Object Model (a collection of APIs that lets JavaScript talk to and manipulate CSS). The intentions of CSS OM developers are to expose newer, deeper access into how a browser is processing and thinking about CSS. These aspects will allow developers to write in a more CSS plugins-like fashion; something we haven’t been able to achieve as of yet. If the CSS Object Model sparks your interest I encourage you to read that spec too.
Houdini Who?
Imagine you could write a plugin that acted more like a browser patch than a JavaScript plugin. What if you had access to inject your own logic into how a browser parses, paints, and renders pages? What things could you “teach” the browser instead of relying on logic on top of the page to compute?
Currently we’re stuck with the way a browser processes CSS, but with Houdini the hope is that we’ll have the ability to rearrange and prioritize so we can calculate values using intelligent approaches, or control the rendering to hide flaws. JavaScript and CSS Object Model APIs lend CSS the same kind of access, control, and power that JavaScript and DOM APIs give to HTML. According to Tab Atkins, Houdini also uses Typed OM and Parser API logic and these are the underlying techs for custom At-Rules letting you specify Element Query rules in your stylesheet and have them handled by JavaScript.
There is a site solely dedicated to tracking its progress at ishoudinireadyyet.com, but in the meantime let’s consider some other potential solutions.
Use an iFrame; Problem Solved
Using iframes to wrap elements is clever approach most certainly, but unfortunately it still isn’t a true solution to the problem; more a creative hack. Read more about this trick from the blog of Tab Atkins.
CSS Contain (Life Raft Not Included)
Although not stabilized in specification form, this property is meant to be useful on pages that contain many independent widgets. The docs claim it can be used to prevent one widget’s CSS rules from changing others on the page. A property value of strict suggests it can avoid many of the problems of container queries, but this isn’t the entire solution; only a piece to the puzzle.
One major issue regarding container queries is that the children and their content can have an effect on the size of the container. This can be avoided in theory by using CSS containment, but let’s look into the actual issue that causes this dependency between elements.
Cyclic Dependencies: the Container Query Nemesis
Take a look at the following talk by Dan Tocchini (you might want to start video from the 10:00 mark as Vimeo doesn’t allow time stamps).
Why can’t an element be responsive to its size? Cyclic Dependencies. Here’s a graphic recreated from the video above to clarify:
Each box depends on the constraints of its containing box (width in this case), and this is where the cyclic dependencies appear. There is a constant relationship between these bound elements that occurs naturally. This type of behavior also exists with
:hover events as Tommy Hodgins explains in this video.
Cyclic dependencies is where a large chunk of the folks who use the term “container query” become stuck because:
- It’s a legitimate problem as CSS already suffers from it.
- There’s nothing developers can do to work around it as it requires some heavy rewriting to the CSS language itself.
- It would require some tweaks at the browser level.
The good news is that browsers are beginning to show some evidence of working around these problems as discussed prior with Houdini.
Future Outlook
There happens to be a CSS Element Queries (dream) spec by Tommy Hodgins; and whilst only a dream spec, it’s very impressive the lengths taken to actually put words and suggestions to the conversation. He’s also compiled a site that lists developers working on container queries appropriately titled “Who is Working on Container Queries”.
After all my research I’m still left wondering why the majority of our community isn’t building this way when we can? We’ve had the ability to build this way before CSS @media was supported in the browser, but it appears we became sidetracked. We went from having no clue about “responsive best practices”, to discovering how to achieve various results using @media; and that spread like wildfire. Articles discussing “Media Query-free responsive layout” using smarter display models such as Flexbox and Grid illustrate that we’re having a difficult time divorcing responsive layout from media queries.
Check out this presentation by Eric Portis (Contain Your Excitement) in which he discusses that very point; with so many roadblocks, just how do we advance the web platform as a whole?
Here are a few common soundbites you’ll hear regarding element queries:
don’t 👏 you 👏🏻 dare 👏🏼 settle 👏🏽 for 👏🏾 javascript 👏🏿 container queries
— Zach LeatHERMAN 🎃⬆⌨ (@zachleat) October 6, 2017
- I’ll take a look once it's an approved CSS spec (it might never be…)
- I’ll only support it once a browser supports it natively (the features are supported, but there’s no sugar for element queries specifically).
- I don’t want to use JavaScript for styling because “That’s Bad®”
I think intl solutions will be JS based and those will inform CSS-only APIs. We shouldn’t ignore tmp solutions just because they require JS.
— Phil Walton (@philwalton) October 6, 2017
It feels like Houdini can sometimes be a way to say “we can’t bother to waste our time on this so let’s let *them* figure it out”
— Sara Soueidan 🐦 (@SaraSoueidan) October 6, 2017
As I’ve experienced over my career, developers rarely expressed issues using JavaScript to add support for @media with IE8 because we required JavaScript to add styling power where browsers lacked. However, using JavaScript already in the browser to enhance CSS? That’s heresy for many; even some of those who are totally happy using JavaScript to assemble HTML.
The ideas mentioned in prior sections are certainly allowing developers to work on their own ideas, but we need to start coming together more frequently, compare notes, find a standard approach and lock it in. In my personal view we won’t be able to divorce JavaScript from CSS when it comes to element queries so we need to embrace it. Anyone waiting for a pure CSS approach might be at the train depot for many, many years to come.
Parting Thoughts
Are you using element queries in your own work? Are element queries a lost cause due to the highly opinionated viewpoints? I hope this discussion helps to spark consideration that will allow JavaScript to have a seat at the table so we can build exceptionally flexible components for the ever-changing web. As always, please post your thoughts in the comments section and happy coding.
Special Thanks
A big thanks to Tommy Hodgins for his time and valuable knowledge on this topic and also for all his work keeping up on this community-sensitive topic.
Additional Links
- Working around a lack of element queries on Filament Group
- presto-points on GitHub
- What the Heck are Element Queries & Container Queries? by Tommy Hodgins
- GSS: Layout Reimagined on Web Design Weekly
- Element Queries by Tommy Hodgins
- eqcss on GitHub
- CSS Element Queries on GitHub
- cssplus on GitHub
- Element Query Demos Collection on CodePen
- Element Queries, And How You Can Use Them Today on Smashing Magazine
- houdini
- Intent to Ship: ResizeObserver
