In Ye Olden Days of Webbe Development™️, if we wanted to create websites and applications that were responsive, it meant writing a series of media ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Great article! Intrinsic sizing is awesome, and definitely a better approach for most use-cases.
Nowadays the main use for media queries is when you need to completely change how an element works. For instance, switch your navigation to a hamburger menu on mobile.
Also, there's much more to media queries than just screen sizes. Things like user preferences (reduced motion, color scheme, etc) are relatively new additions that takes a great role for accessibility. And a whole bunch of awesome new stuff is coming right up ;)
We need media queries more than ever, just not for sizing
This is a super fair point!! I was laser-focused on the responsiveness use case when writing this article, but user preferences and accessibility are really good examples of where media queries still shine. Thank you for adding this comment 😊
Nice article -
clampis the single biggest tool to use in the box here. I find working with grids a pain in the butt, compared to flex.However...
This is not against you, so please don't take it as a personal criticism. Because everyone makes this mistake. But people who write about CSS really gotta stop writing this nonsense about EMs and REMs.
EMs are a nightmare to work with specifically because they are a proportion of their parent element and in the simple example, it's too much to really have to comprehend when writing clean styles
So you revert to REM? But REM is literally bound to a root value, (usually 16px as default, commonly reset to 10px by
:root { font-size: 62.5% }.)This nonsense about 'herp, derp, are you still using pixel sizes' -- well, newsflash, using REM is just the same as using an explicty pixel size as far as I can tell. You just write it in a different format.
The REAL reason for using REM is to tie to your measurements to a single base size in a way that means a change to the root size would cause your UI to scale nicely in a proportional way.
I would like to hint you that making your font-size explicitly with 'px' values and not say REMs or EMs would make your user's browser typography preference overruled. Meaning that there would be no scaling of your font-sizes if the user chose to do so in the browser settings. So, it's always better to use resizible units like REMs unless you want something to have the same font size no matter the user's preference.
What did you not get about:
EMs are just recipes for disaster.
Your original comment makes little sense to me then. Why make an obvious point about the difference between EM and REM when the author quite literraly stated the fact that EMs should generally be avoided and REMs should be used instead. You then go on about saying REMs and PX values are just the same..when in reality they aren't, simply 'couse of the fact that REMs are scalable and PX are not. They are only the same when looked at from coding perspective...not to the browser and users who alter their settings only to find out, to their dissapointment, that the UI hasn't changed. I'd kindly advise you to edit your comment accordingly and not to restate what author had already stated in the blog b'couse it leads to unnecessary confusion for the readers.
Ty and wish u successful coding. Sry for the long comment :/
This is only true if you set the base value to be a pixel value. Ideally you wouldn’t touch it and allow the user to decide the base size. This is 16px by default but fully depends on the size of the text a user has selected.
This is great because larger text requires more whitespace, which is exactly why you would use REM for spacing as well because it scales with the font size of the user!
The mistake developers make is setting the base REM value to be a hardcoded value.
This article makes many valuable points but one place I think media queries retain a role is in the detection of pixel density. Relying on screen dimensions alone is not always sufficient to identify the most appropriate screen presentation.
That's a very fair point! I think there are still specific use cases where you might want media queries - but in general I think they shouldn't be the first thing we reach for anymore.
I'm not a fan of all-or-nothing approaches, which is why this article is called "You Probably Don't Need Media Queries" and not "Stop Using Useless Media Queries Immediately!!!" Only a Sith deal in absolutes 😉 There are exceptions to every rule, so I agree it's unwise to throw out a tool entirely.
Sadly, many iOS devices last longer than Apple support and many older iOS devices are stuck with iOS 12.x. To make matters worse, iOS says that "the device has latest updates" in settings, when the real status would be "your device is no longer supported and should but be used to interface with internet".
In 5 - 10 years we can probably do as you say, that's nice, honestly media query will still have a place also they aren't just for screen size, print, accessibility etc to name just a few purposes. Still exciting ☺️
This is a good summary of how to responsively position website elements ... but remember that designing for multiple devices (or 'sizes') isn't just about the position of text and images, but also how content is edited: how much text is shown, and how images and videos are presented. A mobile website is not just a desktop site squeezed into a smaller form factor, and vice versa. Maybe that's a different article ...
Agreed!! Creating a truly responsive layout is a blend between design and development. In this article, I chose to focus exclusively on the development and technical angle, but maybe you're right and there needs to be a part 2 looking at the UX side of the problem!
Great article!
Thank you very much for putting this together!
Tl;dr
With your line of code (below), how can first and last column widths be set when the number of columns are dynamic?
Example:
Holy Grail layout where:
<aside>appears/disappears when users click on items in the center<main>.<nav>should be a fixed width of250px<main>should be1fr<aside>should be300pxIs there a way to dynamically add/remove the right
<aside>and not have to write a second line to cover the difference?codepen.io/dragontheory/pen/dyZbJP...
Thank you again for your time and effort. It is greatly appreciated!
No mention of container queries?
Container queries are cool, but still experimental and not widely supported yet: caniuse.com/css-container-queries ☹️
In this article, I wanted to focus on code folks could put to use right away. But I do think these are something to keep an eye on, for sure!
Oh sure, but they're set to be a game-changer. Thought it was worth a mention is all :).
It's been a long... Long long long long time in the waiting
I read this article the other day and it made for an engrossing read. A terrific article actually.
The migration from using media queries to some or all of the things above makes sense.
As it stands, there will be many developers who will be reluctant to jump ship instantly as many are still quite at home with the classic RWD approach using media queries.
I would love to see a video where a developer hand codes (from scratch) the same website layout, one using media queries and the other using lot of whats shown and mentioned in this article. and timing the whole thing. I'd be intrigued to see which one takes the longest.
Reviving this olde thread because I recently discovered and started using: Utopia. Like a lot of these solutions it dosen't entirely eliminate the need for a media query but it works very well in a lot of situations where I would have previously used a media query.
This is a really great article. Well written in easy to understand language. I agree with Jordan Brennan, I've purposely never bothered to learn clamp(). My mistake, it's a great utility. Thanks for explaining the subject so clearly.
If you into clamp or not keen of the extra mental load of using clamp then check out github.com/bglw/postcss-fluidvars
It's a simple postcss package that takes your design max and min and applies fluid styles to it via css variables. For example "font-size: var(--s-18-32)" gives you a fluid font size between 18px and 32px for your design min and Max.
I guess it’s time for me to throw away some code. 🥲
Haha I also ignored clamp for a long time. Thanks
Wow, thanks fot this, I will have a go with all these techniques in my next side projects.
I like everything you said. 100% agree with the advice given. What I find a little obfuscated is the scope of your article. Which, I saw you replied to on a user comment.
Let's start here...
HTML table layout design is a plague upon the earth that may never die... email. Need I say more? (Pretty sure the "e" stands for "evil", not "electronic". :))
Okay... so let's say the scope of your article is limited to web browsers.
Some solutions don't include Chinese based, government controlled, device configurations. Aka... all of China.
Okay... so let's say the scope of your article is limited to web browsers outside of China.
Some of the solutions you provide do not work on all device configurations. Say safari browsers... mobile browsers.
The articles scope is now limited to web browsers outside of China that aren't safari mobile browsers.
The point? You're right! There "probably" are use cases that "don't need media queries". There may be workflows that could be explored for some of the use case solutions you have provided. But ultimately userbase will control scope and best practices. i.e. technology; demographic; device configuration and compatibility.
My advice? Don't let being "easy" make your solution less "complete". Define your scope before your technology. ;)
Thank you for the wonderful read. I have a feeling I could talk a lot of "shop" with you.
I do see your point here, but in general, I think the responsibility for deciding what technologies work or don't work for a specific use case are ultimately up to the developer and not the author.
I did (as you noted) make sure to say "probably" or "often" and not "definitely" and always", because there's always something that won't work for someone, haha. I also tried to use the article tags to specify audience (you'll see it's tagged with #webdev, in line with your first point), and only include CSS features with mainline browser support (the 2-3 most recent versions of Chrome, FF, Edge, and Safari). In general, that means the percentage of folks who can use these will be high – but of course, never 100%. As someone who was an email dev for many years, I can tell you that most email devs know the state of the landscape pretty darn well, and wouldn't look at an article like this and assume that it would work in their context. I'm sure the same goes for devs who know their userbase has other limitations that inform their tech usage. I'll also throw out there that not everything listed in the article has the same level of browser support – someone who can't use the math functions may yet read this article and learn about
vworremand be able to put those to use.But, in the end, you're right – an informed decision can only be made by the developer who has the full context on the project. My hope with this post was just to prompt people to reconsider what they might have been doing purely out of habit, and possibly introduce them to a new bit of CSS they hadn't tried before.
And thank you for leaving a comment! I think the comments section is a great place for folks to call out and hash out these kinds of edge cases, so other newer devs who read the article can learn a little more about the process of making these kinds of informed choices about technology usage.
Doesn't work on all browsers yet sadly :( But super useful
Actually, clamp has full modern browser support currently! caniuse.com/css-math-functions
There are still a few weird ones that don't support, but in general these are safe to use for the vast majority of your users!
Lots of my clients still use Safari 13 so.. yeah :( If you don't need to handle that then it's great indeed!
Ahh, bummer! ☹️ But good that you have that kind of data about your userbase and can accommodate them! That's the most important part.