This weekend I read a flurry of articles and emails about container queries.
There is a lot of optimism for this new technique that exactly zero modern browsers. Like all emerging ideas on the web, it is great to be ahead of the wave to better understand what is coming.
But does this mean death to the media query?
I don’t think so.
Whenever there is a new technology or technique that comes out, proponents and early adopters will often slam the existing technology. They will say it is terrible, here is an example of how, and you should use the new technique today.
Watch out.
Now, I think using container based queries will solve some real problems. But I also don’t think media queries are going away.
Here’s why.
- It will be awhile before there is any real browser adoption
- Fragmentation in the naming structure being used by polyfills
- There is no accepted best use case polyfill at the moment. It is as bad as JavaScript libraries with new ones popping up frequently. Why reinvent the wheel?
- Using container based queries has a performance hit of loading the polyfill. I took a look at one such polyfill at it was over 800 lines of JavaScript.
- Possible performance issues with bolting on a reflow technique such as this.
- A polyfill will cause issues with frameworks that reflow the dom: react, angular, and ember to name a few.
The defining point between a media query and a container query is which base object you are measuring.
In all cases the media query measures the size of the browser window. With a container query (with polyfill) you can measure any html element.
I think media queries are working well. Mostly you can get a specific sized grid on desktop (or expand it to full width), and make changes as the viewport (the size of the browser) get smaller in width.
Where this falls apart is when you get near the breakpoints.
Most desktop layouts have 3 or 4 column arrangements. The problem is that as you approach the media query breakpoint some of your columns can get skinny, causing elements to wrap or overlay other elements.
This is most obvious in tablet portrait orientations.
In a similar way looking at mobile layouts you have the same issue as the viewport gets larger, towards the media breakpoint. Most mobile layouts are a single column or have elements aligned (or floated) left or right.
This is most obvious in phablet (such as the iPhone 7 Plus) mobile devices which are becoming more and more popular. Rotating the screen is not great, because you have a full desktop style view which is tiny and difficult to navigate.
So, with most responsive design these two use cases are not great. Tablet portrait and phablet devices.
There are a couple of existing solutions you can use today.
- Change your media breakpoints so you avoid awkward reflow. This can be done in frameworks such as ZURB Foundation by just changing the Sass breakpoint variables.
- Create many more breakpoints to have more control. This is a bad idea and makes things much more difficult to maintain long term.
Often in responsive web projects people can get overly concerned about this “awkward space” around the media query breakpoints. Often this is shown by resizing the browser on a desktop computer from full width to the smallest size and seeing the weird bits that shake and squirm just before or after the breakpoints pops.
There is not much advantage to burning time on these issues.
I suggest the following instead.
- Come up with a LCD ( the Lowest Common Device) that you know (from analytics) or can guess about your audience. For example, iPhone 4. Design so it is usable on this device. Note my use of the word usable.
- Come up with an ideal device. It should look the best here, but degrade nicely to your LCD.
- Test against a variety of common known devices (you can get this from analytics) or take a good guess. You can use a tool such as Chrome DevTools or BrowserStack to accomplish this.
- Test the different orientations of each device.
Here, look for things that make the project un-usable or look very broken on specific devices. In short, look for large visual errors.
Focus on where you have the majority of traffic first.
For example, if you only have 5% traffic to a certain device, it might not be worth the investment to make the experience awesome on this device. If it works good enough, just leave it.
Now, as we move into (perhaps) the age of container queries there will be a better solution to these problems.
By understanding and creating breakpoints specific to the containers, you can create modules that reflow to make these edge cases (the tablet portrait, phablet, and future devices) work much better. The most common use case is that of a media object reflowing from a vertical orientation to a horizontal orientation.
source: http://alistapart.com/article/container-queries-once-more-unto-the-breach
Now what you are seeing above is possible today with media queries. However, what container queries make possible is for elements to resize in their respective resizing column. Confusing, I know.
What is smart about this is that you are creating more “self-aware” responsive patterns. We are no longer thinking about devices.
We are now thinking about grids, columns, and graceful resizing at a component level.
Brad Frost calls them “layout-agnostic components.” I agree.
source: https://twitter.com/brad_frost/status/662518090572296192
If used appropriately, we could be entering soon an era where smaller components can self configure based on the space they have available.
Now in some use cases, I would argue that it might be worth approaching this technique today. However, if you fall into that category you have to understand the problem from a holistic standpoint.
This is the realm of the Design Systems Engineer.
- Keeping abreast of new developments that can significantly improve the user experience of our products.
- Someone who understands the underlying technologies and how they can be implemented.
- The leader that can understand the pro’s and con’s and weigh the advantages and disadvantages before rolling out something like this out to production code.
Do you have someone on your team that is an advocate for your users, design, and engineering process? If not I can help.
