Basic queries (or "container queries" if you must) continue to make their way into conversations between responsive web designers, but their inclusion in any specification and the current landscape is not clear. In this article, we will discuss issues related to elements and community consensus between developers and standards working groups.
What are the queries for items?
Element queries allow elements to "react" to their own constraints, regardless of screen size constraints. This is the most important detail that one has to understand. Media queries as we know them are 100% responsive for layout, but the responsive layout is not 100%
@media queries. Modules, components, interface elements will always grow and shrink with the screen, but never react alone, that is why
@media is not not the complete solution to our problems.
Take a look at this raw demo item queries using eqcss :
During my discussions on this topic with Tommy Hodgins (a petitioner for element and creator queries from eqcss ) it seems that people are always aware of both "queries "elements" and the separate concept of "container requests". The consensus seems to be divided into a few different areas:
Here is another example where I can change the CSS according to the width of the video. Totally unrelated to the size of the window. pic.twitter.com/O6lbDBJvFf
– Wes Bos ???? (@wesbos) October 6, 2017
I want Houdini. I think it will allow us to create concepts that browsers can use to become native.
– Snook (@snookca) 6 October 2017
Want to make a splash in the world of web development? Be the one who makes a functional implementation of container queries with Houdini. ????????♂️
– Chris Coyier (@chriscoyier) October 10, 2017
So, what's on the wish list for developers?
- Develop Houdini in a working model and present it as a perfect case of use towards our needs. At the present time, the CSS working group is focusing on Houdini
There is a site entirely dedicated to tracking its progress to ishoudinireadyyet.com but in the meantime, consider other potential solutions.
Use an iframe; Problem solved
Using iframes to wrap elements is certainly a smart approach, but unfortunately it is still not a real solution to the problem; plus a creative hack. Read more about this trick from Tab Atkins's blog .
Although not stabilized as a specification, this property is meant to be useful on pages containing many independent widgets. The documents claim that it can be used to prevent the CSS rules of a widget from changing to others on the page. A property value of
strict suggests that it may avoid many problems of container queries, but this is not the complete solution;
A major problem with container queries is that children and their contents may have an effect on the size of the container. This can be avoided in theory using CSS containment, but let's look at the real problem that causes this dependency between elements.
Cyclic Dependencies: The Nemesis of the Container Query
Take a look at the following interview by Dan Tocchini (you might want to start the video from 10:00 because Vimeo does not allow it to time stamp).
Why can not an item be sensitive to its size? Cyclic dependencies. Here is a graphic recreated from the video above to clarify:
Each box depends on the constraints of its box containing (
width in this case ) And it is there that the cyclic dependencies appear. There is a constant relationship between these related elements that occurs naturally. This type of behavior also exists with
: hover events like Tommy Hodgins explains in this video.
Cyclical dependencies are where much of the people who use the term "query container" get stuck because:
- This is a legitimate problem because CSS is already suffering. ]
- There is nothing that developers can do to work around this problem because it requires a major rewrite of the CSS language itself.
- This would require some browser-level tweaks.
The good news is that browsers are starting to show evidence of working around these issues as previously discussed with Houdini.
Prospects for the future
It turns out that there is a CSS Element Queries (dream) spec by Tommy Hodgins; and while only a dream specification, it is very impressive the lengths taken to actually put words and suggestions to the conversation. He also compiled a site that correctly lists developers working on container queries entitled " Who Works on Container Queries ".
After all my research, I still wonder why the majority of our community does not build this way when we can? We had the opportunity to build this way before CSS
@media was supported in the browser, but it seems that we have become sidetracked. We went from having no idea about "best practices", to discover how to get various results using
@media ; and that spreads like wildfire. Articles dealing with "adaptive media-free layout" using smarter display models such as Flexbox and Grid illustrate the fact that we have a hard time divorcing the responsive layout of media queries.
Discover this presentation by Eric Portis ( contain your excitement ) in which he discusses this same point; With so many roadblocks, how can we advance the web platform as a whole?
Here are some common sounds you will hear regarding item queries:
– Zach LeatHERMAN ????⬆⌨ (@zachleat) 6 October 2017
- I'll take a look once it's an approved CSS specification (maybe it will never be …)
- I will only support it once a browser will support it natively, but there is no sugar for item queries specifically.)
will be based on JS and these will inform the CSS APIs only. We should not ignore tmp solutions simply because they require JS.
– Phil Walton (@philwalton) October 6, 2017
One has the impression that Houdini can sometimes be a way of saying "we can not bother to waste our time on it so let them understand it"
– Sara Soueidan ???? (@SaraSoueidan) 6 October 2017
Many thanks to Tommy Hodgins for his time and valuable knowledge on this subject and for all his work. keep abreast of this community-sensitive topic.