For the last several months, I and some folks at Igalia have been working on this space. We’re very interested in helping find the connections that bring together developers, implementer and standards bodies to solve the problems.

Internally, we have had numerous sessions to discuss past proposals and tackle challenges. I’ve been researching the various user-space solutions: How they work, what their actual use is like on the Web, and so on. In developer space we’ve worked a lot with folks active in this space: I’ve met regularly with Tommy Hodgins and Jon Neal, and had discussions with folks like Eric Portis, Brad Frost, Scott Jehl and several others.

But we’ve also talked to people from Google, Mozilla and Apple, and they’ve been very helpful and willing to chat – both commenting on and generating new ideas and discussions. I really can’t stress enough how helpful these discussions have been, or how willing all of the CSSWG members representing browser vendors have been to spend time doing this. Just during the recent travel for the CSS Working Group face to face, I had numerous breakout discussions – many hours worth of idea trading between Igalians and browser folks.

I wish I could say that we were ‘there’ but we’re not.

As it stands it seems that there are kind of a few ‘big ideas’ that seem like they could go somewhere – but not actually agreement on whether one or both of them is acceptable or prioritization yet.

Current ideas…

There does seem to be some general agreement on at least one part of what I am going to call instead “Responsive Design for Components” and that is that flipping the problem on its head is better. In other words: Let’s see if we can find a way talk about how we can expose the necessary powers in CSS, in a way that is largely compatible with CSS’s architecture today… even if writing that looks absolutely nothing like past proposals at first.

There seems to be some agreement at large that this is where the hardest problems lie and separating that part of the discussion from things that we can already sugar in user-space seems helpful for making progreess. This has led to a few different ideas…

Lay down small, very optimal paths in CSS

One very good idea generated by lots of discussion with many people during CSS Working Group breakouts sprang from a thought from Google’s Ian Kilpatrick…

I am constantly impressed by Ian’s ability to listen, pull the right threads, help guide the big ship and coordinate progress on even long visions that enable us to exceed current problem limits. You probably don’t hear a lot about him, but the Web is a lot better for his efforts…

The crux of the idea is that there seems to be one ‘almost natural’ space that enables a ton of the use cases we’ve actually seen in research. Some community members have landed on not entirely dissimilar ideas: creating something of an ‘if’ via calc expressions to express different values for properties. The idea goes something like this:

Imagine that we added a function, let’s call it “switch” which allows you to express something “like a media query” with several possible values for a property. These would be based on the available-inline-width during the layout phase. Something like this…

.foo { display: grid; grid-template-columns: switch( (available-inline-size > 1024px) 1fr 4fr 1fr; (available-inline-size > 400px) 2fr 1fr; (available-inline-size > 100px) 1fr; default 1fr; );

See, a a whole lot of the problems with existing ideas is that they heave to loop back through (expensive) phases potentially several times and make it (seemingly) impossible to keep CSS rendering in the same frame – thus requiring fairly major architectural changes. It would need to be limited to properties that affect things only during layout, but another practical benefit here is that it would be not that hard to start some basic prototyping and feel this out a little in an implementation without actually committing to years of work. It would be, very likely, deliverable to developers in a comparatively short amount of time.

Importantly: While it makes sense to expose this step to developers, the idea really is that if we could get agreement and answers on this piece, we would be able to discuss concretely how we sugar some better syntax which effectly distills down to this, internally. Nicole Sullivan also has some ideas which might help here, and which I look forward to learn more about.

Better Containment and

There is another interesting idea generated primarily by David Baron at Mozilla. In fact, David has a whole series of prposals on this that would lay out how to get all the way there in one vision. It is still being fleshed out, he’s writing something up as I write this.

I’ve seen some early drafts and it’s really interesting but it’s worth noting that it also isn’t without a practical order of dependencies. Effectively, everything in David’s idea hinges on “containment in a single direction”. This is the smallest and most fundamental property – the next step is almost certainly to define and impement that and if we have that then the next things follow more easily – but so do many other possibilities.

This information as a property potentially provides an opportunity for an optimization of what would happen if you built any system with ResizeObserver today, where it might be possible to avoid complete trips through the event loop.

It isn’t currently clear how some questions will be answered but David is one of the most knowledgable people I know, and there’s a lot of good stuff in here – I look forward to seeing more details!

Some new experiments?

Another idea that we’ve tossed around a bunch at Igalia and with several developers punts on a few hard of these hard questions whose answers seem hard to speculate on and really focus instead on the circularity problem and thinking about the kind of unbounded space of use cases developers seem to imagine. Perhaps it “fits” with option B even…

These would be a kind of declarative way, in CSS, to wire up finite states. They would focus on a laying down a single new path in CSS that allowed us to express pattern of what to observe, how to observe it, how to measure and say that an element was in a particular state. The practical upshot of this is that not just Container Queries, but lots and lots of use cases that are currently hard to solve in CSS, but are entirely solvable in JS with Observers become suddenly possible to just express via CSS without asking a lot of new stuff CSS – and doing that might present some new optimization opportunities, but it might not — and at least we wouldn’t block moving forward.

So what’s next?

In the coming months I hope to continue to think about, explore this space and continue discussions with others. I would love to publish some research and maybe some new (functional) experiments with JS that aim to be ‘closer’ to a path that might be paveable. We have raw materials and enough information to understand some of where things are disjoint between what we’re asking for and the practical aspects of what we’re proving.

Ultimately, I’d like to help gather all of these ideas back into a place where we have enough to really dig in in WICG or CSSWG without a very significant liklihood of easy derailment. Sooner rather than later, I hope.

In the meantime – let’s celebrate that we have actually made progress and work to encourage more!

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: