When Ethan Marcotte wrote this piece outlining the concepts behind Responsive Web Design, I wonder if he knew how popular the concept would become. Or that it would be mainstream in just a few years. Today, every responsive site on the net relies heavily on media queries to adapt the layout and other elements to the size of the viewport. It’s almost like a bit of magic. We suddenly don’t have to create separate code, files and the works for each mobile device size. Our website magically ‘responds’.

But sometimes, I wonder if we took Ethan’s words too literally. That we got complacent about media queries. We pounced on media queries as the golden solution for responsive designs… and stopped looking beyond.

Don’t get me wrong. I love Responsive Web Design. I love that it enables us to show the same content, well enough, on all kinds of device sizes. And I love media queries — the technology that makes it possible for me to change layouts based on the device size (simplistically speaking). But the more I work with them, the more painfully aware I am of how inadequate and grossly overused they are.

Media Queries: The Origins

Those of you who are familiar with media queries, just bear with me for a minute.

Media queries came about from the need to tailor presentation to a range of output devices, without changing the content itself. A media query checks the media type against the user agent string, and if there’s a match, it goes on to check against certain physical attributes of the device, like height, width, orientation, etc. This is a simple and effective way to serve different presentations on devices with varying dimensions. It’s no coincidence that the need for media queries grew along with the increasing adoption of smart phones and other mobile devices worldwide.

The most commonly used media query features are the ones for height and width. For the browser window or view port there are width, height, min/max-width, min/max-height and for the device there are device-width, device-height, min/max- device-width, min/max- device-height. So you can effectively specify how you want things to change when the viewport or device size changes.

Yes, that’s more or less what it’s all about. Why am I repeating the basics? To draw the focus back to the basics of media queries — the basic concepts that we tend to overlook in our love for media queries:

  1. Media Queries were meant to address the problem of displaying the same content across multiple device sizes.
  2. They are not modular.

And this is where media queries start becoming a problem — when you really want to build modular, independent components.

Adjusting Elements to the Container, Not Viewport

So imagine you’re working on an ecommerce site. Trying to be modular and write good code, you create an element, say my_product, to represent each product. This element has an image of the product and some text describing it. On the home page you want all the product elements to line up, four in a row. On the page for the “Buyer’s Guide”, you want them to line up vertically, one below the other, in the right side bar. Reasonable request. And common enough.

Home page full width products

Products displayed on a home page at full width.

Products in the sidebar

Product’s Displayed on a different page, in the side bar.

So how do you go about doing this? Media queries? A media query will check the viewport size only. In this case, the viewport size is the same in both these layouts. We haven’t even gotten around to considering different device sizes. We just want the my_product element to display differently depending on whether its container is narrow (i.e. limited to the sidebar), or wide (i.e. spread across the whole page). We can’t use media queries for this. Is there anything else in CSS that let’s us do this cleanly? Sadly no. There are a couple of hacks, and scripts that can help; but no clean way (that I know of) to do this. Heydon Pickering hit a similar wall when trying to make his design independent of the content and number of elements.

Modularity Goes Out the Window

To handle this, I’d have to maintain code to style my_product differently, depending on where it is used. If I want to make this responsive, and account for different device sizes, I’m in for more trouble. I’d have to figure out and maintain different breakpoints for this element, depending on the device size. I’m not even going to get into how contorted the code will get. You can look up Ian Storm Taylor’s account of struggling with media queries, Scott’s issues over at FilamentGroup, and Tyson Matanich’s discussion of the problem. Yes, I’m not the only one struggling with this.

I like simple, clean code. I like to keep it modular. I like DRY. I do not like having the same code sprinkled around in multiple places like confetti.

It’s a basic task — if an element gets too narrow (or small or whatever), change the style a bit. There should be a simple way to do it without getting all tangled. There should be a way to link the style of an element to its container, Instead of always linking to its viewport size or the device dimensions.

Workarounds

A few creative people, who struggled with this, have tried to make things easier for the rest of us mortals. Some innovative workarounds to address the current lack in our CSS specifications are:

These are all good. And they serve the purpose. But they each have their own limitations and add in complexity. We need something simpler, cleaner, built into CSS.

Why Don’t We Have Element Queries Yet?

There’s been much discussion about having ‘Element Queries’ — along the same lines as media queries but tied to the component rather than the viewport. RICG is even working on a draft for the use cases and requirements. But it is still in the initial stages. There are a few practical issues that need to be sorted out first. The main issue relates to circularity. There are many ways you can specify an element’s size depending on its contents. What happens when those contents in turn depend on the size of the containing element? What comes first — the chicken or the egg? The debate is still on about the best way to handle this.

But like other problems that appeared impossible in the past, I’m sure this can also be worked out. It’s not impossible. It’s more a matter of the problem getting the attention it deserves. With media queries hogging the limelight, the discussion around element queries isn’t gathering enough momentum. While media queries help us with RWD, they are limited. We need to look beyond.

Media queries and ‘element queries’ are complementary. They address different situations and needs. Just because we now have media queries, doesn’t mean we should sit complacently and not push for further growth in CSS. We need to thrash out the best way to address the issue of element queries.

Over the next few years, the internet is poised for explosive growth, with more websites (good and bad!) being created every day than ever in the past, websites more complex than ever in the past. The majority of developers seem to be happy with what they have at the moment and are too busy, or lazy, to look towards the future. We need to look ahead and make sure we have the right set of tools to handle the complexities. Else we’ll have a few billion websites, with spaghetti code strewn all over.

How have you been handling this issue so far? Do you think the time’s ripe to get the focus onto element queries?

Tags: element queries, responsive web design, RWD
Once upon a time, Richa was a savvy techie & manager, in the semiconductor software industry. After her miraculous escape and recovery, she now works from her garden, creating websites, writing about technology, business & entrepreneurship; and helping others escape the cubicle lifestyle.
Comments
Stephanieboucher

Thanks Richa, this article answers some questions relating to a project I'm working on at the moment. I'll be very interested in developments in this area.

jpdevries

Thanks Richa,

This post sums up the troubles I've been running into better than I could have myself. I've been experimenting with flexbox and individual mutable web components over at Markup.tips and am desperate for element queries!

It is exciting to see the velocity of web standards continue to accelerate. The fact that element queries are even being discussed is promising.

richajn

Stephanie, JP,
Ya, I know, it is so not fun dealing with the tangle of code.

You might want to try out https://github.com/BoomTownROI/boomqueries which seems better than the options listed above. Found out about them after the post was already up (gah!)
If you run into issues with it, I can put you in touch with Craig Anthony

ralphm

This article certainly provides a nice example of where element queries would be useful. All the same, I'm not convinced that it's so hard to use current CSS to handle the issue reasonably efficiently. Much of the styling for the my_product element are shared over the two scenarios. The differences can be contained in separate CSS blocks that target a parent. For example, my_product in the sidebar can always be set to 100%, which will cover responsive variations.

So yes, it involves a bit of extra code, but nothing that's going to break your page sizes.

In a way, I rather like the restraints forced on us by the current options in CSS, as it forces us to ask if these fancy layouts are really necessary anyway. Are sidebars even worth having any more? (Just playing devil's advocate here. stuck_out_tongue )

molocLab

Great article!
I'm working on the same issues for several months.

This is my personal solution: https://github.com/molocLab/context-queries

richajn

I think it depends on the situation. In some cases, the extra complexity is just not worth it.

[but sidebars, yes, I think we still need them. Where else can we put crazy ads and a long list of blog categories and even the kitchen sink wink Honestly, I think even with sidebars, it depends on the context. Use them ONLY IF you really need them. Not just because every other site has them.

thommars

Hey Richa, thank you for an awesome article on an interesting topic smile

I recently started working with embedded content, and keep running into this problem.
The way i have tried to solve it is by setting responsive css classes on the parent container when the container width relative to font size grows beyond a threshold, so that the designer has some classes to work with.
I'm super excited to see further development in this field
Here is an article I wrote on how I deal with this problem: http://h5p.org/blog/responsive-h5p-content

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!