{"id":342370,"date":"2021-06-21T08:41:56","date_gmt":"2021-06-21T15:41:56","guid":{"rendered":"https:\/\/css-tricks.com\/?post_type=newsletters&p=342370"},"modified":"2021-06-21T08:41:59","modified_gmt":"2021-06-21T15:41:59","slug":"256-when-to-use-container-queries","status":"publish","type":"newsletters","link":"https:\/\/css-tricks.com\/newsletter\/256-when-to-use-container-queries\/","title":{"rendered":"256: When to use @container queries"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

[Robin]<\/strong>: Max B\u00f6ck asks when should we use @container<\/code> or @media<\/code> queries?<\/a><\/p>\n\n\n\n

While I think container queries will eventually replace most \u201clow level\u201d responsive logic, there are still a lot of good usecases for trusty media queries.<\/p>

A combination of both techniques will probably be the best way forward. @media can handle the big picture stuff, user preferences and global styles; @container will take care of all the micro-adjustments in the components themselves.<\/p><\/blockquote>\n\n\n\n

Once @container<\/code> queries get support in browsers and it becomes a part of our daily work, I can see how this question might be confusing for folks getting started in web development. Heck, I can see it being confusing for me! And yet, although Max makes a lot of great points in that piece, I think the quickest explanation between the two could be this:<\/p>\n\n\n\n

@media<\/code> queries are for page layout and @container<\/code> queries are for components.<\/strong><\/p>\n\n\n\n

That\u2019s a little simplistic but when it comes to component design (like a navigation or a button) you likely want that component to be aware of its environment and the width or height of its parent. Let\u2019s say you want to throw that dropdown component into the sidebar, or grab that button group and put it into a bigger space than it was initially designed for. Those are the moments when @container<\/code> queries will absolutely shine.<\/p>\n\n\n\n

Layouts are a bit different because we don\u2019t often want to nest layouts. If you have a 12-column grid, it\u2019s unlikely you\u2019ll want to nest that grid within another grid component\u2014instead, you\u2019d want the elements to inherit the grid. And that\u2019s precisely what subgrid<\/a> is for:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

See how nested elements above (like the gray rectangle) is aligned to the grid gap of the outer container? That\u2019s good ol\u2019 subgrid and that means we can mostly avoid nesting grid elements within grid elements.<\/p>\n\n\n\n

Anyway, I reckon in almost all instances when we\u2019re designing a component we\u2019ll want to use @container<\/code>. But, saying that, I really hope @media<\/code> queries aren\u2019t treated later like the <table><\/code> element is today, where a ton of people are somehow under the impression that they are bad practice just because they were the best option to lay things out at the time.<\/p>\n\n\n\n

Even though @container<\/code> is on the horizon and it will be fancy new tool under our belt, @media<\/code> still has its place and is still useful and relevant in layout and design.<\/p>\n\n\n\n

\n\n\n\n

[Chris]<\/strong>: I’d revise my earlier statements that the vast majority of *-queries we write in the future will be container queries. Now I’d guess that, on a greenfield project, if you’re authoring that project from front-end components, it’ll be predominately (like maybe 90%) @container<\/code> queries. If you’re refactoring an existing project, especially one that isn’t really component-based, it’ll maybe be 50% @container<\/code> and 50% @media<\/code>. Still just guessing here\u2014it’s fun think about. These are such early days that I don’t think it’s even entirely certain it’ll ship in all the browsers, or even in the form we’re all experimenting with now.<\/p>\n\n\n\n

\n\n\n

Using the outline<\/code> Property as a Collapsible Border<\/h3>\n\n\n

For some reason I\u2019ve always avoided the outline<\/code> property. But it has its uses! Take this example where Carter Li uses it as a collapsible border for tables<\/a>. Just like this:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

There have been many days and nights where I\u2019ve been building a table and had to fight the borders of rows and columns because they didn\u2019t work the way that I expected them to. In the past, you\u2019d have to do some negative margin magic to make sure each cell lines up properly.<\/p>\n\n\n\n

This post shows there\u2019s a few gotchas that are interesting. For instance, an outline<\/code> is always going to add a line around the entire shape, unlike border<\/code> where you can say border-right<\/code> only. Also, changing border-width<\/code> is going to trigger layout in browsers, which makes sense. But it\u2019s a good reminder that although there\u2019s a long list of animatable CSS properties<\/a>, there are only four things in CSS that can be animated safely without impacting performance: position<\/code>, scale<\/code>, rotation<\/code> and opacity<\/code><\/a>.<\/p>\n\n\n\n

\n\n\n

Making Tables With Sticky Header and Footers Got a Bit Easier<\/h3>\n\n\n

Speaking of tables, even though position: sticky<\/code> is amazing, there\u2019s been one thing that\u2019s always been a bit tricky about it. If you want to make a table header stick to the top as you scroll, then it wouldn\u2019t work in Chrome particularly well.<\/p>\n\n\n\n

That\u2019s all fixed now<\/a>, thankfully:<\/p>\n\n\n\n

Sounds like a big effort went into totally revamping tables in the rendering engine in Chromium, bringing tables up to speed. It\u2019s not just the stickiness that was fixed, but all sorts of things<\/a>. I\u2019ll just focus on the sticky thing since that\u2019s what I looked at.<\/p><\/blockquote>\n\n\n\n

So, if you want to make a table with sticky tables and<\/em> rows like in this example below, you can totally do that:<\/p>\n\n\n\n

Perfect Tooltips With CSS Clipping and Masking<\/h3>\n\n\n

I tend to forget that CSS clipping and masking can lead to really interesting ideas, so when I stumbled over this post by Louis Hoebregts this week where he walks us through the mask-image<\/code> CSS property<\/a>, I was pretty excited.<\/p>\n\n\n\n

Here\u2019s what Louis built:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Notice the bottom of that image where there\u2019s a curved arrow pointing down? There\u2019s a number of ways you can do that, but using mask-image<\/code> isn’t what I normally reach for. Chris explained this CSS property a while back<\/a> and here\u2019s how it works.<\/p>\n\n\n\n

First, you have an element with a background-image<\/code>. Then you could pull in an SVG graphic to use as a mask over it:<\/p>\n\n\n\n

.element {\n  background-image: url(background.png);\n  mask-image: url(star.svg);\n}<\/code><\/pre>\n\n\n\n
So you\u2019ll see something like this:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Just like the background<\/code> CSS property, we need to tell mask-image<\/code> to not repeat itself. But we also need to set the mask-size<\/code> as well. And once we fix those things…<\/p>\n\n\n\n
.element {\n  background-image: url(background.png);\n  mask-image: url(star.svg);\n  mask-repeat: no-repeat;\n  mask-size: 100%;\n}<\/code><\/pre>\n\n\n\n
…this is the effect we end up with:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
So what Louis does is mask his tooltip shape with that little arrow using mask-position<\/code> to place it at the very bottom of the element. And if you ask me, that\u2019s pretty darn smart.<\/p>\n\n\n\n
This is also a good reminder that there\u2019s a lot of things you can do with this technique. Sarah wrote this great piece a while ago about when to use masking and clipping<\/a> when it comes to SVGs:<\/p>\n\n\n\n
Think about masking as a way to apply complex, detailed, and shapes with varying opacity over another element. This can lead to really beautiful visual effects and performant alternatives to other techniques. For instance, animating gradients can be really CPU-intensive. But in the graphic below, we\u2019re animating the mask instead of the gradient to the same visual effect, and it\u2019s a lot less heavy.<\/p><\/blockquote>\n\n\n\n
Masking is a whole other newsletter, but I love this demo from Craig Roblewsky<\/a> that helps explain how a mask can change the color of an underlying element:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\n\n\n
Inline Styles as Classes<\/h3>\n\n\n
This is some evil stuff here, folks. Sam Thorogood opened the gates of hell<\/a> to show us how we can write CSS like this:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Chris then blogged about<\/a> how a classname like this works. You can write some HTML like the following to apply those styles:<\/p>\n\n\n\n
<div class=\"display: flex;\"> \n  <!-- content goes here -->\n<\/div><\/code><\/pre>\n\n\n\n
I apologize profusely that you had to see that but technically, display<\/code> and flex<\/code> above are two separate CSS classes but you could also write something like this and it would work too:<\/p>\n\n\n\n
[class*=\"padding\\: 1rem\\;\"] {\n  padding: 1rem;\n}<\/code><\/pre>\n\n\n\n
Again, I cannot begin to apologize enough for this despicable code you\u2019re seeing and my lawyers have told me that I am not legally responsible for any damage I\u2019ve caused in sharing this any further. They also told me to say that you could write a Sass function or something to create all these classes automatically. But! This would be the work of pure evil and I do not even remotely recommend this. It\u2019s just sort of neat to know that you can<\/em> do this.<\/p>\n\n\n\n
Even if you shouldn\u2019t.<\/p>\n\n\n\n
\n\n\n
Useful and Useless Code Comments<\/h3>\n\n\n
Jim Nielsen made some notes about what constitutes a “useful” code comment<\/a>:<\/p>\n\n\n\n
If somebody says a comment isn\u2019t adding any value, I would ask: to whom?<\/p>
Personally, I\u2019ve never liked the advice that writing obvious comments is bad practice\u2014probably because I write obvious comments all the time.<\/p><\/blockquote>\n\n\n\n
Jim reminds us that what we see as useful might not be what other folks consider useful. Perhaps a team doesn’t have many front-end experienced folks, so commenting helps explain non-trivial CSS things. I could certainly see that being helpful.<\/p>\n\n\n\n
I guess my advice to myself when writing comments is this: what am I likely to forget in the future when it comes to this code? Will I forget that this CSS property or class interacts with this other one? Will I forget that I have to do this one weird hacky thing because of the code in another file? That\u2019s the really valuable stuff to write a comment about and pairs well with Sarah’s thoughts on code comments<\/a>.<\/p>\n\n\n\n
\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Sponsor<\/p>\n\n\n
axe DevTools<\/a><\/h2>\n\n\n
Is your website accessible? Deque’s axe DevTools Pro makes accessibility testing easy for dev teams.<\/p>\n\n\n\n
Find and fix potentially critical issues while you code. No expertise required. Build more accessible experiences and get started for free today<\/a>.<\/p>\n\n\n\n
\n
Get started<\/a><\/div>\n<\/div>\n\n\n\n
\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Sponsor<\/p>\n\n\n
ImageKit.io<\/a><\/h2>\n\n\n
CSS is powerful for creating overlay effects but has a few drawbacks. The same code doesn’t work across devices, or the overlay effect is lost when a user downloads the image! How do we overcome this? Read on to understand how we solve this problem<\/a>.<\/p>\n\n\n\n
\n
Read article<\/a><\/div>\n<\/div>\n\n\n\n
\n\n\n\n
[Chris]:<\/strong> In-app command palettes are pretty sweet. Often they manifest in UI as a bar<\/strong>. Like the macOS spotlight thingy, which predominantly searches but also does other things. <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
And think of a tool like Alfred<\/a>, also literally a bar, that does countless things.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Those are system wide<\/em> though. Sometimes these bars are app-specific.<\/p>\n\n\n\n
Command palettes aren\u2019t always bars (essentially search inputs) though. Consider the command palette of VS Code. A keyboard command brings up an autocomplete-powered super menu of damn near anything VS Code can do. It\u2019s bar-like\u2014it\u2019s just the bar isn\u2019t there at all unless you ask for it.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Chrome DevTools has a similar palette.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
I\u2019m a fan. For one thing, it makes everything keyboard-accessible. For another, if your brain knows this tool can do something, you just forgot where they tucked the function, it’s no matter; you can find it here. <\/p>\n\n\n\n
But the “all-powerful” command palette isn\u2019t the only way these things show up. Philip Davis has a great article looking at some examples<\/a> of command palettes that are more focused. Like Notion’s insertion palette.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
That’s not everything<\/em> that Notion can do, it’s a subset of things contextualized to the action of inserting a new block. Notion has a Quick Find command too, and lots of other keyboard shortcut giving it powerful, yet contextual commands.<\/p>\n\n\n\n
The new-ish WordPress block editor has its own version, the block inserter which I’ll use to insert an image of it:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Philip has other interesting examples in there like Raycast<\/a>, which is a command palette with command palettes inside. <\/p>\n\n\n\n
Command palette’s becoming more mainstream is one of my favorite trends in modern applications. There are lots more good examples that I’ve enjoyed using.\u00a0Linear<\/a>,\u00a0Alfred<\/a>,\u00a0Fig<\/a>,\u00a0Xcode<\/a>,\u00a0VSCode<\/a>,\u00a0Sketch Runner<\/a>, and\u00a0CtrlP<\/a>.<\/p>
<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"
[Robin]: Max B\u00f6ck asks when should we use @container or @media queries? While I think container queries will eventually replace most \u201clow level\u201d responsive logic, there are still a lot of good usecases for trusty media queries. A combination of both techniques will probably be the best way forward. @media can handle the big picture […]<\/p>\n","protected":false},"template":"","acf":[],"_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters\/342370"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/newsletters"}],"version-history":[{"count":10,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters\/342370\/revisions"}],"predecessor-version":[{"id":342908,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/newsletters\/342370\/revisions\/342908"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=342370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}