Container Queries make the most important lesson I've ever learned, a reality

The lesson - reusability

“Build each component so that it can be re-used everywhere”. That’s the most important lesson I’ve ever learned as a front-end developer. But why? It means that you’re building everything intending to be

• easily changed
• simple to understand
• without any outer spacing

But there’s one big issue with this theory: styling.

The issue - media queries

Although the intention is good, in practice it’s quite hard to create a reusable component that fits all of these criteria. That’s because the style changes are based on the window width and not the width of the component. Let’s take this Card component as an example.

See the Pen Untitled by GRRR Tech (@GrrrTech) on CodePen.

It’s designed to be quite big and therefore the font size is quite big as well. Which looks great. But when you want to re-use this card at a different location, let’s say an aside, the big font size looks quite awkward.

See the Pen Card with large title within aside by GRRR Tech (@GrrrTech) on CodePen.

The current solution - settings

To ensure the reusability of this component, and to prevent this awkward font size, we use a “setting” to alter the styling. You could also call this props if you work with React or arguments if you work with a function. For this Card component, we could create a setting for the font size with a value of small, medium, or large. This setting would be added as a data attribute to the HTML as: data-font-size={fontSize}. That’s the hook to apply the correct styling to. This works great, but this could create an awful amount of settings for each component and that’s bad for the maintainability of the project.

The new solution - Container Queries

Luckily, there is a new solution, soon to be implemented in all major browsers: Container Queries. Currently, the browser support isn’t good enough to start using it in all projects (at least for us), but when it is, it’s great!

There are a lot of good articles written about Container Queries (MDN, CSS tricks) so I will not dive into the details of the syntax. But in general, it’s a way to style components based on the size of their parent, not the size of the window.

To get back to the example of the cards. With Container Queries, it’s no longer needed to create a setting for the font size. You can just set the correct font size based on the width of the parent, not the width of the window. Like in this CodePen:

See the Pen Card with large title within aside with container queries by GRRR Tech (@GrrrTech) on CodePen.

A more complex issue - Layout changes

The example above is nice, but you could also argue that there’s nothing wrong with the solution of the setting. And I agree with that. I do think you have a bit more control with the Container Query solution for the responsive font size. But overall, both solutions work.

The solution with the settings gets harder when the correct setting is based on the size of the module. Let’s take a look at a Card again. This could accept a setting for the orientation (horizontal or vertical). For smaller screens, the orientation should also be vertical. And when the size of the module is large enough, it can be changed to horizontal.

To implement this with a setting, you can add an eventListener to the parent component and update the setting when the window’s size is larger than X. But that doesn’t feel right because because you would need some JS to fix a styling issue. Which feels like overkill to me.

Luckily, Container Queries can also help you with this issue! Let’s take a look at a Card again. The layout should be: Image on top and text below for all smaller screen sizes. But when the component gets enough room, the text should go to the right of the card.

Conclusion

Although our current solutions with settings work, there is a more elegant solution: Container Queries. While browser support isn’t good enough yet for us, we will start implementing this solution whenever it’s possible. When thinking about Progressive Enhancement, we might start implementing Container Queries quite soon. For instance, on some CMS tweaks or small optional details. Just to get a feel for it and to get used to the syntax.

Container queries provide us a native solution to an issue we otherwise would solve with “settings” and sometimes with JavaScript as well. To me, it feels great that we can remove the JavaScript part of the current solution.