Why Browsers Need Element Query Support

Image courtesy of unsplash.com

Product design is at a very exciting point in time — especially in the web. Technology is constantly evolving and at break-neck-speed and introducing exciting new avenues for web app development. Tools like A-Frame allow web developers to create VR apps, and so many more. As product designers, we’re able to do more than ever, and technological constraints are far less restricting.

I’m also an enthusiastic supporter of methodologies for UI design and development such as Atomic Design, Pattern Libraries & Style Guides. Designing and developing applications from an atomic level makes consistency a breeze, enables scalable and extensible applications, and gives us the ability to easily (or at least a little more easily) update the design of our applications.

And of course, we all design & develop mobile-first.


Can’t media queries do the job?

With media queries, we’re able to create fluid and responsive designs. We’re given a lightweight solution for displaying content differently depending on the user’s viewport size & media type. We’re also able to easily take advantage of progressive disclosure with minimal code.

@media only screen and (min-width: 40rem) {
.component {display: block;}
}

Where media queries fail

The problem lies in the fundamental modularity of our UI patterns. Patterns need to have the flexibility to have behavior and display modifications based on their relation to a page layout, not just the viewport itself.

Let’s say we’re creating a table pattern. We want to display content stacked in mobile screen sizes, then in-line at tablet screen sizes:

Concept table. Makes use of responsive design and progressive disclosure.

This works wonderfully as a standalone pattern or in a simple page layout. But when this pattern is used within a template, we’re able to see things starting to fall apart. For example, look what happens when we use this pattern in a more restrictive page layout like a dashboard:

The in-line display causes content to overlap, and sometimes overflow the pattern itself.

The pattern is still pulling attributes from the viewport’s width, rather than the pattern’s container within the template. Naturally, the pattern becomes broken in implementation. The best workaround we have right now is to either make template-specific (or sometimes even page-specific) overrides to the pattern’s css in order to make it look not so hideous.

Because that, it’s nearly impossible to have 100% modular code. Nearly every implementation will require some sort of workaround in order to get the patterns to display how the designers intended them to, which basically defeats the entire purpose of creating an atomic, mobile-first, modular pattern library in the first place…

Element queries to save the day!

What we need is a solution that is viewport and media agnostic. A solution that serves styles based on the containers that wrap our patterns. Then we can define stylistic changes that need to happen if the pattern itself falls within certain dimensions.

.component:min-width(40rem) {
display: block;
}
A pattern defined with element queries will render properly when placed in templates

Element queries seem to be the best answer for front-end developers and product designers to get a better handle on creating modular, atomic UI patterns without the hassle of edge-case workarounds. Sounds great doesn’t it!? Let’s take a look at browser support:

Bummer. Not even recognized by Caniuse.com

So why are element queries not supported?

The problem is that this concept is still being hashed out. From the perspective of atomic design, we can answer some of the questions in debate. The base component should have queries that alter it’s appearance based on the width of the component itself, which will allow complete modularity. When placed into various page templates, the component will independently respond to the area it is contained within.

There’s a lot of debate as to how it should be done, but one thing is for certain: Product designers and developers need this solution. And to borrow a phrase from your boss, we needed it yesterday. Element queries are, by far, one of the most useful tools for product designers and front-end developers in today’s responsive, mobile-first world.