Hasty Treat - The Status of Element Queries / Container Queries

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, Node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest web development treats coming in hot. Here is Wes, Barracuda, Bos, and Scott El Toroloco, Tolinski.

Welcome to Syntax ESLint this Monday.

Hey, Stitchery. We're gonna be talking all about container queries, element queries. Well, we'll talk a little bit about what the heck they are and why they might be useful, what the current status of them, and why it's not as easy of a problem as we would all like it to be. My name is Scott Tolinski. I'm a developer from Denver, Colorado, and with me JS always is the Wes Bos.

Sup, everybody?

Sup, sup, sup, sup, sup, sup, sup, Wes?

Not too much. I'm just excited to learn about element queries. We've complained about this enough on the show. Like, where is element queries? Yeah. And then this blog post came out sort of detailing it. It made me feel bad for her complaining.

Yeah. I think that happens often in web development. You don't necessarily know what's going on. Yeah. Part of that problem is we see the problem.

Right? This thing that we wanna fix, but we, like, don't immediately see all the people working hard to try to fix that problem. And it's too easy to just be like, I don't want this thing. And then the people that are working on it are probably super annoyed with people like us. So yeah. The same thing happened with

Node modules.

Like, you've no idea. Like, for for us, it's just, like, just add node modules. Just do it. Just press the button that says add them and add them. And then, like, the people working on it are like, you have no Node how complex this is

Yeah. Behind the scenes. I know. It's so easy being a complainer about stuff like that.

But one thing you don't want is complainers about your tools or projects, and that's why you're gonna want to go ahead and use an error and exception Sanity handling tool. High quality, Scott. Thank you. I'm when when I got it, I got it. And this I'm I'm running a no sleep here. But to finish that sentence, it would be, century at century.i0.

You're gonna wanna sign up using the coupon code Sanity treat, and you'll get 2 months for free. Now what is Sentry? Well, Sentry is the error and exception handling tool that basically allows you to see, handle your errors with just about any platform or service that you're running. And, seriously, Sentry works with everything from any type of back end language that you're possibly working with to front end projects, serverless, and more. All sorts of, very famous companies trust Sanity with their bugs. And, you know, I don't trust a lot of people with my bugs. So if I'm gonna trust anybody with bugs, it's going to be century.

They errant Airbnb, Disney, PayPal, Microsoft, Dropbox, Mozilla Square. Can you name bigger companies than these? And they are all loving century. So you want to check out a century at century. Io again, use the coupon code Sanity treat, all lowercase, all one word.

And, again, if you use it, they support it. Apple, Android, GitHub.

I don't know. Just start naming technology. I'm just gonna start technology random generator, and Sentry JS gonna support it. So, let's get let's get into this, container queries or element queries. Now I've always I've always personally called them element queries, but it seems like container queries might be the more popular term. Have you always gone one way or the other with that one? Yeah.

I'm not sure what I've been saying, but I think container queries makes more sense because you want to do something when the container is a certain size. I guess elements is the same thing, though. You wanna do something when the element is a specific size. Anyways, the it's kind of the same idea JS that, we have media queries, which is based on the viewport size, but we don't have container queries, which means that you could have a component, and that component could live anywhere on your website. And depending on how wide or high or any other, aspects of it, generally, its width and height you're gonna be worried about. Depending on the width and height that that thing fills out, then style it a little bit differently. Mhmm. And there's some movement in this.

Even around JavaScript, we've Scott, well, resize observer. So Yep. Hell, yeah. We'll talk about that. We are going to talk all about it. So where where are we at right now with this, Scott? Yeah. So okay. So I think the,

the biggest thing for you to do if you are interested in more information about this beyond this particular episode is to peep this blog post by, Brian Cardell. And, it's really just an overview of exactly what's been happening, and we'll try to do essentially an outline of this blog post in this episode. So if you're looking for more details beyond what we're saying here, by all means, read this episode.

So, really, again, like you mentioned, we have these, you know, this this issue. Right? We've been promised that we will get our Lego pieces. Right? Our Lego pieces, these things we just plug in and they just work. But I, for instance, let's here's a here's a good one. Right? I have my a grid of cards on my website. Right? And when the browser is wide, that grid of cards breaks into 3 columns of cards. Right? But those cards individually can change in size based in 3 columns. But then when you go down a little bit shorter, it goes into 2 columns. And then in mobile, it's 1 column. But those cards should look differently based on their own width, the Node the browser view ports width. Because if you do the media query and say, okay, at this point, the card text should be this size, well, you'll have a grid of 3 cards up, and the font size will be huge. And then when you have a 2 card grid, font size will be small or whatever. So, really, these container queries are going to fulfill the end of the promise of having Lego pieces that we can just drop in and have them adjust accordingly to, whether or not it is a full width or a half width or whatever it takes up. So, that's really why I want them personally. There's a lot of things that I I would use this for, and I I do have an alternate solution in place of which we'll talk about. So that's why I want them, but let's talk about sort of some of the problems that the team and the people that are working on this problem are facing because that's really why we don't have them yet JS because of all of the problems. Right? So what kind of problems exist? Well, as developers, we mentioned in the the very first part of this the show that, like, we we can just declare Wes want this thing. Right? And, in fact, it's so easy to say, we should just have a media query, but have it be an element query. That's it. Okay. Node it just functions based on the element rather than the viewport. And so the the the blog post mentions it's like most of these discussions start off with talking about how do we write them, and that's, like, sort of the wrong place to start for various reasons because it totally ignores so many of these gigantic and gigantic problems with starting from that by just saying, oh, this is how it should just work. Right? But in reality, we need to look at the way CSS already works and the way that the the the paint models already work before coming up with a solution that just drops in. So they were saying that many of the initial or even just ideas that they come up with in general require some major fundamental changes to how browser engines work. And that's not really practical to just say, hey, all of you browsers, we need to have some brand new way that you render CSS And testing that amongst browsers, having that going and keeping it all performant at the end of the day is going to be way too much of a a thing to be able to just say, hey. Just do it. Right? That will take several years of testing, trying, and all sorts of things. So, I I found this really interesting quote throughout this blog post that says this is from like I mentioned, this whole whole blog post is Brian Cardell. So this is a quote from him. It says, did you know, for example, that there are multiple many year long efforts with huge investments underway already aiming at unlocking many new things in CSS? There Yarn, and I don't mean Houdini.

So what he's saying is that on top of all of these other changes that are going on and that they're they're really working to solve some huge problems in CSS, well, tackling another one of these things since asking a whole new aspect of the engine to be changed is kind of a huge monumental task on top of all of the other stuff that's being worked on within CSS.

So what actually has been happening? Because it seems like the problems are just really large. Right? Having to write whole new engines. I mean, it's, like, sort of a lot Scott of problems. Right? So what has been happening? If you read this blog post, you'll see the word lots of discussions hap you'll see lots of discussions hundreds of times in this post. So that's really what it JS. Discussions and dead ends. Another quote here is, how do we make this into more solvable problems, and how do we actually make some progress and mitigate risk, take a step, and actually get something to developers.

Right now, they have been doing lots of experiments, lots of trying things, and it seems like there's just these huge, big problems. So of which, there are 2 sort of interesting paths that we have right now that aren't element queries themselves or container queries themselves, but certainly are things that we can use in the meantime. Now one of these, I don't have any experience with, one of which I have quite a bit experience with. So, they mentioned containment and then resize observer.

Yeah. I saw blog posts on the containment the other day, and I thought it was pretty interesting, but I haven't dug too deep into it. I think we we have that on the docket for, an entire show. Yeah. I think that's a good idea to do an episode entirely on containment and resize observer,

just to talk about how we can use them. I linked in here a a WebKit blog post about, using resize observer specifically as a way to basically write element queries, and I think that's a a nice little interesting read through.

One interesting note is they said that resize observer was inter implemented in bra in all browsers in about 2 years. That's pretty darn fast. Right?

2 years to get a feature like that in? Yeah. And that's not just like, functionality that you can add. It's not like adding a polyfill to a new array method, which you can just pop in. Like, this was fundamental low level stuff where that feature was Scott you couldn't do that beforehand unless you were to just, like, continually pull or run a set time out. So this had to have some lower level stuff where the I'm assuming what happened was the paint engine would then bubble up information about what changed to higher level JavaScript APIs.

Yeah. It's very interesting. If if you've never used resize observer, it basically, it observes for when the window resizes

and updates. Yeah. It's like a you listen instead of listening for clicks, you can kinda listen I'm using air quotes here. Yeah. Listen for, not listen. You observe when things change size, and then when that happens, it triggers a callback, which gives you access to the elements that have or all of them, actually. It'll it'll tell you which ones have changed and not. And this Node right now for me is probably

the most useful in terms of actually getting container and element queries working, although I did find some post CSS plug in, which we can talk about later, that I haven't used before.

So where has all this progress gone? Well, again, lots of discussions discussions with Google, Mozilla, Apple, Scott people.

And there's basically just a ton of discussions happening about the right ways. Lot of big ideas, some of which could go somewhere, some of which could go nowhere, and there has been no there's been nothing yet that, has been implemented that anyone can use. They did post a a neat little snippet here of 1 proposed idea, and this proposed idea uses something like a switch function that could be used. Instead of what you would think of as like a normal media query, Wes it looks like is a switch, and then you'd have several properties of which would have a parameter saying the size, it being greater than this, then have the value be this. The size, you could almost look at this like a straight up JavaScript switch statement, obviously, with slightly different syntax.

What do you how do you feel about this one?

It's tough because my initial reaction to new things in CSS is always just like, oh. But, like, CSS variables, everybody saw that. It was like, oh, awful. And then, like, no one's complaining about that anymore. It's fine. You know? It works great. The SynX is a bit a bit funky, but they had to obviously keep it backwards compatible. They couldn't just add, like, a dollar sign or something like that, which would have been cool. So this switch syntax looks I think it looks kinda cool. I Scott assume that it would get really big real quick depending on on what you're trying to do, but it looks fairly similar to, to media queries. I like that there. So the way that it works is that you have, like, basically, a switch function, and then inside of each line of that switch function will be available ESLint size is greater than 1024, then the grid columns will be this. And then if the available inline size is greater than 400, then it's kinda like a like a switch statement or an if statement in your JavaScript code.

It also is using inline and size instead of width and height, which remember Wes did a show on that where they're switching over. By the way, like, a little bit of a side, have you coded anything with the ESLint and block instead of width and height?

I have not. I have not.

Have you?

I tried. Yeah. I did the users Scott tech on that, and then I switched it because of Wes did I switch it? I think it was just I totally forget. I think it might have been browser support, and I didn't want to transpile it. You just don't wanna deal with it. Or it was just too hard to get my whole mindset over to, like, this is that. So I was trying to hard.

Yeah. And I had a couple of people opening issues, and they they didn't know. Same with Gap. I've been starting to use Gap instead of GridGap, because Gap will be coming to Flexbox as well. Interesting. And then I get all these issues with people opening it up and, like, you misspelled it. And I'm like, no. It's it's a thing.

Anyways, you keep going. Yeah. So, I should note that this idea, it says there's a note here that it sprang from an idea from, Google's Ian Kilpatrick. And there JS a neat little note that says, I am constantly impressed by Ian's ability to listen, pull the right thread to 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 probably a lot better for his efforts. So shout out to Ian if you're listening here. Ian, you seem like the man. I do not know you personally, but, I'd never heard of Ian's name before, and I thought that was a really interesting quote about him. But okay. So I thought this this JS another little interesting topic sort of about some of their problems here. And it says that a lot of the problems with the existing ideas is they have to loop it back through extensive phases, potentially several times, making it seemingly impossible to key the CSS rendering in the same frame. So really, a lot of the problems that we're running into are going to be perfect based, right, with how these things will work or or just they wanna like, at the end of the day, if you're introducing something into the browser, it has to be

really buttoned up. You know? Yeah. We sometimes have this problem in CSS Grid as well where like, the problem they're referring to is that if you have, let's say, you have a div that is 500 pixels wide, and then you've got something inside of that is based on the container query. Mhmm. Like, let's say, a header. And then inside the header, you have, maybe, like, an h two that has a container query on it. If the outer div changes, that will then trigger a change on the thing inside of it, which then triggers another thing inside of it, But that becomes a problem when you are sizing the width of the outer div based on the insides, and you can get into this sort of nonstop loop where Node thing triggers another thing, which then changes its size, which then triggers another thing, which then triggers the size. And you just have this infinite loop of things triggering changes on other things. And that is an extremely hard problem to solve because at what point do you stop this thing? Right? Right. And that happens with CSS Grid as Wes. If you have an image that's not loaded and it the column of that is auto and the image then loads, but then, like, the other stuff is based on free space, then that triggers a reload. And imagine you have you throw container queries in there as Wes. Like, what a hard thing to fix. Imagine having to solve these problems,

and not just getting to wonder where they where the the progress is on them. I I I Totally. It's all fantastic, to me, you know, just JS, like, an outside observer. I love any sort of progress on this. So I you know, whatever the solution ends up being, if it ends up being media query like syntax or a switch statement or, one thing they mentioned here is maybe that the answer isn't necessarily that we have to throw this all in in CSS, but there could be some sort of, like, hybrid JS solution, based on resize observer and working with resize observer to make things more, you know, explicitly geared towards element queries.

So I don't know. I'm interested in this. If you are interested in this as well, let us know what your thoughts on container element queries. If you're using any sort of specific plug in or package or technique for dealing with them right now, I wanna know what you're using. I am using a specific technique myself using style components, but I also found this container query package

that is a post CSS package. Have you seen this, Wes? Have you seen this? Yeah. I've seen this. I, well, I just just looked it up when you said it earlier, and I'm just wondering, like, how does it work? It obviously needs a little bit of JavaScript to run on the page. Yeah. In the past, how I've done it is just run a resize observer and add and remove classes or pipe in the width into a styled component, which which can then render the thing based on the width, but not this. How does this work? I don't know. I don't know how it works. I've never seen it until right now. Since I've been in style components plan, I've sort of gotten off the post CSS train a little bit in terms of what what exists and what's out there. Yeah. A lot of that stuff happens for you under the hood, so you don't necessarily have to to worry too much about it. Yeah. Let's see. And JavaScript runtime.

And it looks like this does work with some sort of CSS and JS. I have no idea because I haven't used post CSS within style components.

But this looks really interesting.

It seems like there's movement on it. Last commit was January 27th. Oh, 2019, not 2020. Okay.

So maybe less movement on it than I was making when I initially looked at it, but it looks like it is very usable.

The solution that I've gone with JS modified version of this, a styled container query plug in that I've also linked in the show notes. So this is based on styled components, and it is for use with styled components.

But if you use emotion, I can't imagine it would be too hard to rewrite this package. In fact, I took a comment in the issue queue of here and rewrote my own version of this package myself to fit my own Node. Right? Because I I have very, very specific needs with mine, and this package could have been made a little bit slimmer. And so I slimmed it down, and then I, just included in my own project. And I've been thinking about maybe even open sourcing that. I didn't write most of the code. I copied it and then tweaked it. But, you know, if these packages aren't interested in changing their project up, I might post my own slimmer version of this thing. But for the most part, I found this approach to be really nice where you have, basically, the at or the, ampersand colon container, and then you do serve the min width, max width, and you can do whatever you want. Now I should state that I did run into some problems with this because, like a total dummy, I was adjusting the height inside of my container query. Yeah. And because I was changing the height on it, it was running into some perf issues refiring our resize observer.

And, when you have that maybe about, you know, 20, 25 components doing that all at once, definitely some CPU hit. So I've since wised up to modifying the height in those kind of situations.

Oh, yeah. Yeah. See, that's the thing. It's like like, I'm glad you noticed that, but some people would just like CSS just needs to you seem to be able to use it. And in most cases, it should work fine. Right? Right. And that's really the the the crux of this issue is, how do you get something that works with what we can do in CSS and does so in a way that isn't going to work everybody's browsers.

Cool. Is bork a legit word? I don't know. Is that a Oh, yeah. Okay. Bork bork is I I said that the other day, actually, and, my wife is like, what's bork? Let's look up bork on Urban Dictionary. Looks like it's actually in the actual dictionary to obstruct.

Really? Yeah. It's in the actual Webster dictionary.

Definition of bork.

The sound doggos and puppers make. Uh-huh. Doggo borked a lot at the kidder.

Oh my god. Bork, irreversibly

damaged. My sound card JS borked.

Yeah.

I've I've said something like that. Sound Yarn. Who use the sound card anymore? I know. Right? 2 I remember getting Yarn ago. Sound cards. Yeah. I remember sound cards. Ours had, like, that crappy little microphone on it that you could plug into the port. Yeah. Yeah.

5.1 surround or whatever. I remember I Scott had to buy a sound card to hook up my LG, like, 5.1.

Oh, the days.

Cool. Alright.

I believe that is it. Anything else to add? No. I am fascinated on this topic. So if you have any plug ins or packages that are working well for you to do element queries, go ahead and hit us up on Twitter about them. We will retweet you and ensure that, again, if I end up breaking my slimmed down version of this styled components ESLint its own package, I will also link that into the show notes. We'll see. I've been going along, package crazy lately just realizing that I can open source most of the stuff in my code base. So Yeah. Now that, shout out to Jared Palmer's TSDX. TSDX is just about the most dead simple thing in the world to get, like, a TypeScript package going. So, now that that exists and I'm, you know, into it, I'm just making a lot of packages, man. I'm just I'm just making packages. Just making packages.

Yeah. We'll talk to you in a year when you have 10,000 open issues No. People arguing.

No issues. If you open the issue, I close it. It works.

There are no issues with my packages. Canceling. That's it. I think that's enough. Thanks for tuning in. We catch you on Wednesday.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.