Media queries are a vital part of modern web design, but they’re not always perfect. In this article we’ll take a look at the idea of “element queries”; what many argue is the future of responsive web design.

In the Beginning

Ethan’s article on Responsive Web Design changed the way we build websites, forever. His article inspired and was rapidly adopted by web designers and developers. Approaches such as “Mobile First”, “Desktop First”, and “Device Agnostic” have emerged, design patterns have since been developed, new standards such as the <picture> element have been introduced, and we now have countless options of frameworks that make developing a responsive website easier.

We no longer build websites for a particular screen sizes, browsers or devices. We instead build them so that they’re equally enjoyable on any device, and at any screen size. We do so using “media queries”–not forgetting the viewport meta tag.

Media Queries

Media queries are designed to allow us to mould style rules to a specific environment. One of the most common uses of media queries is to change styles within a certain range of viewport widths. The following code, for example, hides the sidebar when the website is accessed through a viewport up to 720px wide.

Media queries evolved, along with the devices, with several added features such as orientation and resolution . The following example shows how we might use one of these features to serve a larger image size on a high-resolution screen.

Media queries have become a staple component when delivering a responsive experience. Get yourself up to speed by reading these articles, tutorials, and tips on harnessing media queries on our previous posts in Tuts+ as well as all over the Internet.

However

Media queries are not the silver bullet to every situation in responsive web design, in fact, it was never meant to be so.

Today, there are a great range of devices on the market in various sizes and traits, blurring the line between “mobile” and “desktop” (I’m looking at you “hybrid laptops”). For this reason, maintaining a website’s aesthetics, a great user experience, and performance has never been tougher.

At Google IO 2015, Google lets developers to check their website on over 100 different devices.

And once you add things like ads, tables, and legacy content into the mix, the situation can be even worse. Soon enough you will run into the “not so good” aspects of media queries.

Media Queries: the “Not so Good”

Consider the following example. We have a UI component to show our team member profile. We want to use this exact component in a couple of different places on our website. This example shows how the UI is laid out at a 780px viewport width.

In the “user profile” page, we put the user avatar on the left, and the user name as well as the biography on the right.

User profile layout in the "User" profile.

In the “team” page on our website, however, the layout shifts; the user avatar image is now placed at the top, and the user name as well as the biography is underneath. The font size might also be a bit smaller.

User profile layout in "team" page.

This situation can be fixed with media queries. We can, for instance, write the CSS, as follows:

It is fixable, as long as we use some additional identifying classes: .user-profile and .user-profile-card .

However, it also goes against our UI being a reusable component; a UI that can be placed anywhere on the website, being able to adapt to its surroundings.

In this example we want the layout of our component to adapt when wrapped by a small container, instead of when it’s squeezed by the browser viewport. So rather than relying on the browser viewport size to shift the layout, why can’t we do so at the element level?

Element (Container) Queries

The idea of element queries emerged around the beginning of 2012; a couple of years after Responsive Web Design became the mainstream methodology. Unfortunately, there probably weren’t many convincing reasons to bring this up as a web standard at that time–the world was still getting used to going squishy again.

@ianstormtaylor yeah "element queries" has come up now and again — Paul Irish (@paul_irish) January 24, 2012

Web communities began initiatives on their own. RICG (Responsive Issue Community Group), the same group that initiated the <picture> element, eventually added element queries into their issue list while other developers developed a JavaScript library, like EQCSS, to emulate this functionality.

Element queries work similarly to media queries; except that they listen to the element size in lieu of the browser viewport. This enables us to build a truly modular UI system with DRY-er code base. Given the same example, we could rewrite the styles of our UI component with EQCSS, as follows:

Here we don’t care what the viewport width is. As you can see above, as long as the UI is stretched to 480px or wider, we display the .avatar and the .bio side-by-side. When the UI width shrinks down below 480px we let the .avatar and .bio stack and align the content to the centre.

Wrapping Up

Just to clarify, I’m not saying using media queries is bad, not at all. Media queries are wonderful and we have witnessed that on many websites built today. Media queries and element queries can certainly co-exist. However there are lots of design scenarios where using element queries would make more sense than using media queries.

Unfortunately, element queries still have a very long way to go before they finally pass as a web standard; our hope on this rests with all the good people at RICG.

While we wait, we can explore element queries’ potential a through a JavaScript library like EQCSS. And that’s exactly what we are going to do in the next tutorial. Stay tuned!

Further Reading