Thursday, July 20th, 2017
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—”
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.”
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.
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:
- 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.
- 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).
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.
Sunday, April 9th, 2017
Chris rounds up the discussion that’s been happening around container queries, for and against.
Personally, I’d like to see about 100 different use cases fleshed out. If it turns out some of them can be done sans container queries, awesome, but it still seems highly likely to me that having container queries available to us would be mighty handy.
Tuesday, April 4th, 2017
Monday, April 3rd, 2017
Paul’s being contrary again.
Seriously though, this is a good well-reasoned post about why container queries might not be the the all-healing solution for our responsive design problems. Thing is, I don’t think container queries are trying to be an all-encompassing solution, but rather a very useful solution for one particular class of problem.
So I don’t really see container queries competing with, say, grid layout (any more than grid layout is competing with flexbox), but rather one more tool that would be really useful to have in our arsenal.
Thursday, March 2nd, 2017
Unsurprisingly, I completely and utterly agree with Ethan’s assessment here:
I’ve written some code that’s saying, “Once the screen is this size and the element appears in a different, smaller container, use a narrower layout on this element.”
But, well, that’s weird. Why can’t we apply styles based on the space available to the module we’re designing, rather than looking at the shape of the viewport?
I also share his frustration with the “math is hard; let’s go shopping” response from browser vendors:
There’s an incredible clamor for container queries, with folks from every corner of the responsive community asking for something that solves this problem. So personally, I’d love to see at least one browser vendor partner with the RICG, and get properly fired up about this.
We had to drag browser makers kicking and screaming to responsive images (to this day, Hixie maintains it’s not a problem that needs solving) and I suspect even more activism is going to be needed to get them to tackle container queries.
Tuesday, February 10th, 2015
Tim Maughan reports on the same container ship trip that Dan W. is sending his postcards from.
I like the idea of there being an Apollo-sized project all around us, if you just know where to look.
First, towering above and over the ship, are the loading cranes. Vast structures mounted on huge, four-legged frames, they resemble the naked scaffolding of unbuilt skyscrapers, and trigger nostalgic reminders of Saturn V rocket launch towers from the 1960s.
Once in port at night I saw one suddenly fire into life next to the ship in a stroboscopic explosion of lights, before it tracked slowly above my high vantage point, bathing me in the orange glow of a dozen small halogen suns.
Sunday, June 29th, 2014
Guardian beta · The container model and blended content – a new approach to how we present content on the Guardian
This is what Oliver was talking about Responsive Day Out 2 — a new approach to information architecture.
Cast off your sidebars! You have nothing to lose but your grids!
Sunday, December 4th, 2011
James Bridle in untrue art exposé: read all about it!
The comments are simply epic.