Beyond Media Queries — It’s Time to Get Elemental

Originally published at: http://www.sitepoint.com/beyond-media-queries-time-get-elemental/

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.

Continue reading this article on SitePoint

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.

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.

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

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: )

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

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

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.

1 Like

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

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.