12 ms·

Media Queries and Responsive Design

100 points by nhardy 3y ago

LanternLight83 3y ago
This is great, thanks for sharing! I picked up most of this over time, but wouldn't have needed as much with such a great overview as this-- matches all the best practices I learned trying to make sure things looked right c: What I didn't pick up along the way was accessability... anyone got recommendations for lesser known, quality, maybe even first-hand resources on eg. ARIA?
- itsuka 3y ago
  I'm currently going through https://practical-accessibility.today https://practical-accessibility.today course by Sara Soueidan. She is really knowledgeable and, most importantly IMO, she practices what she teaches. Her Twitter feed also has some nice tips on accessibility.
camillomiller 3y ago
Took me a long time to wrap my head around CSS grid to use it like the amazing tool it is. Then chatGPT came around. Having GPT-4 scaffolding the CSS grids I want by just describing them is one of my top-5 uses for it.
chrismorgan 3y ago
@media (max-width: 479.98px) This would be more accurately expressed with negation (though the difference will probably never matter to even a single human): @media not all and (min-width: 480px) This is using widest-compatible syntax, since WebKit only very recently (Safari 16.4) got the Media Queries Level 4 stuff to let you write it in clearer ways. The “not” applies to the remainder of the query: parse it as “not (all and (min-width: 480px))” rather than “(not all) and (min-width: 480px)” which would never match. (As far as I can tell, compatibility charts don’t show this Level 4 query syntax boolean logic stuff at all. Anyone want to do me a favour and file MDN data bug about it? If you do, mention it because otherwise I might finally get round to reporting it later.)
- rado 3y ago
  Yes, "not" is better than fractions.
- benatkin 3y ago
  There's no need to mess with the breakpoints. They're chosen carefully. The article explains why this one works optimally: > Why 0.98px specifically? 0.02px is the smallest division of a CSS pixel that an earlier version of Safari supported. See WebKit bug #178261.
  - ehnto 3y ago
    You shouldn't need arcane knowledge of Safari bugs to evaluate a simple media query. This will break on first encounter with a well intentioned maintainer. The option with the least outside knowledge required is usually the most robust choice I feel.
  - chrismorgan 3y ago
    I’m confused by your defensiveness. What I express has the same browser support, but is correct (rather than leaving a tiny gap that is theoretically possible to encounter, though vanishingly improbable in reality), doesn’t depend on esoteric knowledge of the meaning of a 0.02px difference, and sticks with just the one magic number which is obviously desirable for various maintenance purposes. On the downside, “not all and (min-width: 480px)” is an idiosyncratic spelling, and you run the risk of people reaching for “not (min-width: 480px)” instead, which works in current browsers but sheds support for somewhat older browsers (with Safari being the last to get it, only a couple of months ago). (In the wild, I’ve encountered exact-value overlap, which is obviously wrong and very easy to trigger, −1px, which is obviously wrong and fairly easy to trigger, −0.1px which is fairly safe, and −0.01px, but I don’t recall ever encountering −0.02px.) If the article had used a negated media query, would you be arguing for using a non-negated .98?
    - nhardy 3y ago
      The CSS Media Queries Level 4 spec actually includes fractional pixel values as part of the examples for browsers which do not yet support the range syntax: https://www.w3.org/TR/mediaqueries-4/#mq-min-max https://www.w3.org/TR/mediaqueries-4/#mq-min-max > One approach to work around this problem is to increase the precision of the values used for the comparison. Using the example above, changing the second comparison value to 320.01px significantly reduces the change that a viewport width on a device would fall between the cracks. The .02/.98 values might seem strange, but many popular libraries use these offsets (including Bootstrap: https://github.com/twbs/bootstrap/blob/main/scss/mixins/_breakpoints.scss https://github.com/twbs/bootstrap/blob/main/scss/mixins/_bre...). The way I tend to work with media queries is not writing them directly but rather use a mixin (when using SCSS) or a media function (CSS-in-JS). That way, this weird quirk can be documented just once in an application, leaving anyone curious enough with the explanation. There tends to be an 'upTo(breakpoint)' function which is an exclusive range, and a 'from(breakpoint)' which is inclusive.
rado 3y ago
The author did a great job on that article. But please stop it with the 768px nonsense already. It makes no sense at all and is unnecessarily complicated. The breakpoints should be 600px, 900px etc https://www.freecodecamp.org/news/the-100-correct-way-to-do-css-breakpoints-88d6a5ba1862/ https://www.freecodecamp.org/news/the-100-correct-way-to-do-...
- ehnto 3y ago
  Indeed, the mythical Standard Tablet Size doesn't exist, none of the device psuedo standard sizes are actually standard. Devices come in myriad sizes, and resized browser windows come in many more (even on mobile devices) The most pragmatic solution in my opinion, pick a handful of major layout shift points and fix the layout when it breaks as you resize it, not based on an imaginary universal device size.
- itsuka 3y ago
  I personally prefer sizes that are multiple of 8 because it works well with grid-based layouts and popular CSS libraries and design tools like Tailwind and Figma also adopt this system, although not strictly. However, I agree with your general sentiment that the exact number does not matter much. It will matter less even more when Container Queries become a common practice.
- deleted 3y ago
  [deleted]
kilian 3y ago
Nice overview, though I would advice against using device-specific breakpoints even beyond giving them device-specific names. Phones continue to get larger every year so designs made for 320px specifically started to become unoptimized when phones became 375px wide, and those in turn started becoming unoptimized when 414px became the norm, then iPhone 14 came out at 428px wide and that'll just continue. The best strategy then is to let your site's content and layout guide where your CSS breakpoint should be, and designing for the _range_ between them. If you want a full overview of CSS Media queries, I maintain an evergreen article with everything there is to know: https://polypane.app/blog/the-complete-guide-to-css-media-queries/ https://polypane.app/blog/the-complete-guide-to-css-media-qu...
- nhardy 3y ago
  That is similar to what I was trying to convey. Breakpoints are just that though, the _point_ at which style rules _break_ into different groupings. Viewport _ranges_ exist between breakpoints. It is also a pet peeve of mine that breakpoints get referred to as "mobile", or "tablet". Very much agree on making content work at all screen sizes, and picking points where it makes sense to "break" at different viewport sizes depending on the content. At the end of the day, it is very arbitrary. Thanks for the link!
  - leetrout 3y ago
    I use all my desktop screens split in half. It drives me nuts when I get mobile layouts on a browser set to half the width of my QHD displays.
  - chiefalchemist 3y ago
    The other mistake I've seen with the "mobile" and "tablet" mindset is that "desktop" navs that rely on hover don't translate well when the "tablet" is desktop-esque in size. In general I prefer to presume the user is always touch-based. At the very least, that's their mindset / exportation. Personally, I get annoyed with desktop experience that use hover but don't make it mindlessly obvious that you need to use hover (to get the info I need). Clever might be clever but it's too often a shite UX.
bruce343434 3y ago
Why is it not a thing to query the literal screen size in cm? Instead we have to work with fake pixel measures and scaling factors and a whole bunch of bullshit and edge cases.
- dontlaugh 3y ago
  Or even more accurately, arcseconds at typical viewing distance. This would cover TVs and phones with the same measurement.
- pjc50 3y ago
  For desktop systems the EDID data is not always reliable. Besides, you don't want the screen size, you want the viewport size and the DPI.
  - bruce343434 3y ago
    I think I want the arc length of the viewport. Fonts should have a minimum size based on that, certainly not 11pt or whatever.
  - Wowfunhappy 3y ago
    > Besides, you don't want the screen size, you want the viewport size and the DPI. ...I can think of at least one case where you really would want the screen size, although perhaps it's specialized enough to warrant a separate API. As a user, I have often wished there was a reliable way to view an image on the web at "actual size". Examples would include purchasing band-aids on Amazon, or reading a Wikipedia article about insects. As far as I know, there's currently no good way for websites to offer this, and there really should be!
- chrismorgan 3y ago
  Device diversity is such that that’s useless for general content. People use devices at less than arm’s length and at multiple metres away. Firefox used to have an experimental resolution-independent millimetre unit mozmm, but devices simply don’t tend to expose what you need so most of the time it wasn’t accurate. Browser makers considered standardising such a thing, but consensus was that (a) it wasn’t possible to make it accurate far too much of the time, and (b) it’s almost never what you want anyway (about the only legitimate uses: simulating a ruler, and physically-accurate sizing for comparison with physical artefacts; certainly never on general-purpose web pages), so it was just dropped.
Roark66 3y ago
Really good article. It is refreshing to see not all content created today has to be in a video format or if written is split into 30 pages.
lapcat 3y ago
> To tell the browser that a site is providing an optimised experience for all viewport sizes, you can include the following meta tag in the document <head>: > <meta name="viewport" content="width=device-width, initial-scale=1" /> I see this a lot, but it's actually cargo culting, and all you need is initial-scale. "You do not need to set every viewport property. If only a subset of the properties are set, then Safari on iOS infers the other values. For example, if you set the scale to 1.0, Safari assumes the width is device-width in portrait and device-height in landscape orientation." https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html#//apple_ref/doc/uid/TP40006509-SW26 https://developer.apple.com/library/archive/documentation/Ap...
- zagrebian 3y ago
  That’s Apple. What about Android?
- nhardy 3y ago
  It looks like that advice is specific to iOS. Recommendations elsewhere specify that both device-width and initial-scale should be included for compatibility with all mobile devices, e.g. https://developer.chrome.com/docs/lighthouse/pwa/viewport/ https://developer.chrome.com/docs/lighthouse/pwa/viewport/
- chrismorgan 3y ago
  To begin with: that documentation looks to be ancient, so be careful as it may not reflect reality any more, though nothing stands out as obviously wrong. You’ve skipped over the difference: > Safari assumes the width is device-width in portrait and device-height in landscape orientation Whereas width=device-width means device-width when in landscape (device-width now being the longer axis), which is I think always going to be what you actually want. If what they document is correct, and it does sound right for how I recall it being described some years back, that the page effectively zooms in when you rotate, then it’s just not what you want. Testing in desktop Chromium’s responsive design mode, it does seem to behave reasonably in the presence of <meta name=viewport content=initial-scale=1>. I haven’t checked anywhere else. But if you specify width=device-width, then initial-scale=1 is actually superfluous, that then being the default. I understand that it was part of the common incantation in order to work around Safari orientation change bugs which I think have been fixed for a few years now, but I don’t have anything to confirm it on (really wish they’d provide an emulator for non-Apple platforms) and have never had anyone answer it when I’ve mentioned it here on HN.
dorfsmay 3y ago
Screen size is good for layout but don't forget "pointer". If (not (pointer: fine)) then you really want all your links to be more like button (big target areas easy to hit with a finger), otherwise you're forcing your users to do the zoom-and-click dance, and often completely give up. On the other hand, big button-like links are a waste of space if your users have a mouse, track point or track pad.
- chrismorgan 3y ago
  I generally disagree with this; the sorts of changes you might make for coarse pointers will tend to help the users of coarse pointers too; my mild inclination is to view any use of any interaction media feature as a nudge to reconsider aspects of your design. They’re really just too coarse to be particularly good, hints of how the user might interact with the document. You probably also want (not (any-pointer: fine)) instead of (not (pointer: fine)), as the spec notes suggest: https://www.w3.org/TR/mediaqueries-4/#mf-interaction https://www.w3.org/TR/mediaqueries-4/#mf-interaction. (These spec notes are fairly extensive, because these are delicate matters where it’s easy to make a mess of things.)
  - dorfsmay 3y ago
    When I tried phones and tablets were positive for "any-pointer" (not good!). From my tests the most reliable way to check for a mouse/track point/track pad are (pointer: fine) and (not (hover: none). Personally, as a user, I don't like a menu that take the whole page when on a desktop, I find a top bar or a hamburger work much better, but those don't work with a small enough screen and without a pointer device (mobile devices), where a vertical menu with big buttons is more appropriate. But I'm not a UX specialist nor a designer, so this is what I suggest but obviously follow their specs.
kps 3y ago
Ironic that a brand new article about media queries doesn't use (or mention) prefers-color-scheme.

100 points by nhardy 3y ago

This is great, thanks for sharing! I picked up most of this over time, but wouldn't have needed as much with such a great overview as this-- matches all the best practices I learned trying to make sure things looked right c: What I didn't pick up along the way was accessability... anyone got recommendations for lesser known, quality, maybe even first-hand resources on eg. ARIA?

itsuka 3y ago
I'm currently going through https://practical-accessibility.today https://practical-accessibility.today course by Sara Soueidan. She is really knowledgeable and, most importantly IMO, she practices what she teaches. Her Twitter feed also has some nice tips on accessibility.

camillomiller 3y ago

Took me a long time to wrap my head around CSS grid to use it like the amazing tool it is. Then chatGPT came around. Having GPT-4 scaffolding the CSS grids I want by just describing them is one of my top-5 uses for it.

chrismorgan 3y ago

@media (max-width: 479.98px) This would be more accurately expressed with negation (though the difference will probably never matter to even a single human): @media not all and (min-width: 480px) This is using widest-compatible syntax, since WebKit only very recently (Safari 16.4) got the Media Queries Level 4 stuff to let you write it in clearer ways. The “not” applies to the remainder of the query: parse it as “not (all and (min-width: 480px))” rather than “(not all) and (min-width: 480px)” which would never match. (As far as I can tell, compatibility charts don’t show this Level 4 query syntax boolean logic stuff at all. Anyone want to do me a favour and file MDN data bug about it? If you do, mention it because otherwise I might finally get round to reporting it later.)

rado 3y ago
Yes, "not" is better than fractions.
benatkin 3y ago
There's no need to mess with the breakpoints. They're chosen carefully. The article explains why this one works optimally: > Why 0.98px specifically? 0.02px is the smallest division of a CSS pixel that an earlier version of Safari supported. See WebKit bug #178261.
- ehnto 3y ago
  You shouldn't need arcane knowledge of Safari bugs to evaluate a simple media query. This will break on first encounter with a well intentioned maintainer. The option with the least outside knowledge required is usually the most robust choice I feel.
- chrismorgan 3y ago
  I’m confused by your defensiveness. What I express has the same browser support, but is correct (rather than leaving a tiny gap that is theoretically possible to encounter, though vanishingly improbable in reality), doesn’t depend on esoteric knowledge of the meaning of a 0.02px difference, and sticks with just the one magic number which is obviously desirable for various maintenance purposes. On the downside, “not all and (min-width: 480px)” is an idiosyncratic spelling, and you run the risk of people reaching for “not (min-width: 480px)” instead, which works in current browsers but sheds support for somewhat older browsers (with Safari being the last to get it, only a couple of months ago). (In the wild, I’ve encountered exact-value overlap, which is obviously wrong and very easy to trigger, −1px, which is obviously wrong and fairly easy to trigger, −0.1px which is fairly safe, and −0.01px, but I don’t recall ever encountering −0.02px.) If the article had used a negated media query, would you be arguing for using a non-negated .98?
  - nhardy 3y ago
    The CSS Media Queries Level 4 spec actually includes fractional pixel values as part of the examples for browsers which do not yet support the range syntax: https://www.w3.org/TR/mediaqueries-4/#mq-min-max https://www.w3.org/TR/mediaqueries-4/#mq-min-max > One approach to work around this problem is to increase the precision of the values used for the comparison. Using the example above, changing the second comparison value to 320.01px significantly reduces the change that a viewport width on a device would fall between the cracks. The .02/.98 values might seem strange, but many popular libraries use these offsets (including Bootstrap: https://github.com/twbs/bootstrap/blob/main/scss/mixins/_breakpoints.scss https://github.com/twbs/bootstrap/blob/main/scss/mixins/_bre...). The way I tend to work with media queries is not writing them directly but rather use a mixin (when using SCSS) or a media function (CSS-in-JS). That way, this weird quirk can be documented just once in an application, leaving anyone curious enough with the explanation. There tends to be an 'upTo(breakpoint)' function which is an exclusive range, and a 'from(breakpoint)' which is inclusive.

rado 3y ago

The author did a great job on that article. But please stop it with the 768px nonsense already. It makes no sense at all and is unnecessarily complicated. The breakpoints should be 600px, 900px etc https://www.freecodecamp.org/news/the-100-correct-way-to-do-css-breakpoints-88d6a5ba1862/ https://www.freecodecamp.org/news/the-100-correct-way-to-do-...

ehnto 3y ago
Indeed, the mythical Standard Tablet Size doesn't exist, none of the device psuedo standard sizes are actually standard. Devices come in myriad sizes, and resized browser windows come in many more (even on mobile devices) The most pragmatic solution in my opinion, pick a handful of major layout shift points and fix the layout when it breaks as you resize it, not based on an imaginary universal device size.
itsuka 3y ago
I personally prefer sizes that are multiple of 8 because it works well with grid-based layouts and popular CSS libraries and design tools like Tailwind and Figma also adopt this system, although not strictly. However, I agree with your general sentiment that the exact number does not matter much. It will matter less even more when Container Queries become a common practice.
deleted 3y ago
[deleted]

kilian 3y ago

Nice overview, though I would advice against using device-specific breakpoints even beyond giving them device-specific names. Phones continue to get larger every year so designs made for 320px specifically started to become unoptimized when phones became 375px wide, and those in turn started becoming unoptimized when 414px became the norm, then iPhone 14 came out at 428px wide and that'll just continue. The best strategy then is to let your site's content and layout guide where your CSS breakpoint should be, and designing for the _range_ between them. If you want a full overview of CSS Media queries, I maintain an evergreen article with everything there is to know: https://polypane.app/blog/the-complete-guide-to-css-media-queries/ https://polypane.app/blog/the-complete-guide-to-css-media-qu...

nhardy 3y ago
That is similar to what I was trying to convey. Breakpoints are just that though, the _point_ at which style rules _break_ into different groupings. Viewport _ranges_ exist between breakpoints. It is also a pet peeve of mine that breakpoints get referred to as "mobile", or "tablet". Very much agree on making content work at all screen sizes, and picking points where it makes sense to "break" at different viewport sizes depending on the content. At the end of the day, it is very arbitrary. Thanks for the link!
- leetrout 3y ago
  I use all my desktop screens split in half. It drives me nuts when I get mobile layouts on a browser set to half the width of my QHD displays.
- chiefalchemist 3y ago
  The other mistake I've seen with the "mobile" and "tablet" mindset is that "desktop" navs that rely on hover don't translate well when the "tablet" is desktop-esque in size. In general I prefer to presume the user is always touch-based. At the very least, that's their mindset / exportation. Personally, I get annoyed with desktop experience that use hover but don't make it mindlessly obvious that you need to use hover (to get the info I need). Clever might be clever but it's too often a shite UX.

bruce343434 3y ago

Why is it not a thing to query the literal screen size in cm? Instead we have to work with fake pixel measures and scaling factors and a whole bunch of bullshit and edge cases.

dontlaugh 3y ago
Or even more accurately, arcseconds at typical viewing distance. This would cover TVs and phones with the same measurement.
pjc50 3y ago
For desktop systems the EDID data is not always reliable. Besides, you don't want the screen size, you want the viewport size and the DPI.
- bruce343434 3y ago
  I think I want the arc length of the viewport. Fonts should have a minimum size based on that, certainly not 11pt or whatever.
- Wowfunhappy 3y ago
  > Besides, you don't want the screen size, you want the viewport size and the DPI. ...I can think of at least one case where you really would want the screen size, although perhaps it's specialized enough to warrant a separate API. As a user, I have often wished there was a reliable way to view an image on the web at "actual size". Examples would include purchasing band-aids on Amazon, or reading a Wikipedia article about insects. As far as I know, there's currently no good way for websites to offer this, and there really should be!
chrismorgan 3y ago
Device diversity is such that that’s useless for general content. People use devices at less than arm’s length and at multiple metres away. Firefox used to have an experimental resolution-independent millimetre unit mozmm, but devices simply don’t tend to expose what you need so most of the time it wasn’t accurate. Browser makers considered standardising such a thing, but consensus was that (a) it wasn’t possible to make it accurate far too much of the time, and (b) it’s almost never what you want anyway (about the only legitimate uses: simulating a ruler, and physically-accurate sizing for comparison with physical artefacts; certainly never on general-purpose web pages), so it was just dropped.

Roark66 3y ago

Really good article. It is refreshing to see not all content created today has to be in a video format or if written is split into 30 pages.

lapcat 3y ago

> To tell the browser that a site is providing an optimised experience for all viewport sizes, you can include the following meta tag in the document <head>: > <meta name="viewport" content="width=device-width, initial-scale=1" /> I see this a lot, but it's actually cargo culting, and all you need is initial-scale. "You do not need to set every viewport property. If only a subset of the properties are set, then Safari on iOS infers the other values. For example, if you set the scale to 1.0, Safari assumes the width is device-width in portrait and device-height in landscape orientation." https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html#//apple_ref/doc/uid/TP40006509-SW26 https://developer.apple.com/library/archive/documentation/Ap...

zagrebian 3y ago
That’s Apple. What about Android?
nhardy 3y ago
It looks like that advice is specific to iOS. Recommendations elsewhere specify that both device-width and initial-scale should be included for compatibility with all mobile devices, e.g. https://developer.chrome.com/docs/lighthouse/pwa/viewport/ https://developer.chrome.com/docs/lighthouse/pwa/viewport/
chrismorgan 3y ago
To begin with: that documentation looks to be ancient, so be careful as it may not reflect reality any more, though nothing stands out as obviously wrong. You’ve skipped over the difference: > Safari assumes the width is device-width in portrait and device-height in landscape orientation Whereas width=device-width means device-width when in landscape (device-width now being the longer axis), which is I think always going to be what you actually want. If what they document is correct, and it does sound right for how I recall it being described some years back, that the page effectively zooms in when you rotate, then it’s just not what you want. Testing in desktop Chromium’s responsive design mode, it does seem to behave reasonably in the presence of <meta name=viewport content=initial-scale=1>. I haven’t checked anywhere else. But if you specify width=device-width, then initial-scale=1 is actually superfluous, that then being the default. I understand that it was part of the common incantation in order to work around Safari orientation change bugs which I think have been fixed for a few years now, but I don’t have anything to confirm it on (really wish they’d provide an emulator for non-Apple platforms) and have never had anyone answer it when I’ve mentioned it here on HN.

dorfsmay 3y ago

Screen size is good for layout but don't forget "pointer". If (not (pointer: fine)) then you really want all your links to be more like button (big target areas easy to hit with a finger), otherwise you're forcing your users to do the zoom-and-click dance, and often completely give up. On the other hand, big button-like links are a waste of space if your users have a mouse, track point or track pad.

chrismorgan 3y ago
I generally disagree with this; the sorts of changes you might make for coarse pointers will tend to help the users of coarse pointers too; my mild inclination is to view any use of any interaction media feature as a nudge to reconsider aspects of your design. They’re really just too coarse to be particularly good, hints of how the user might interact with the document. You probably also want (not (any-pointer: fine)) instead of (not (pointer: fine)), as the spec notes suggest: https://www.w3.org/TR/mediaqueries-4/#mf-interaction https://www.w3.org/TR/mediaqueries-4/#mf-interaction. (These spec notes are fairly extensive, because these are delicate matters where it’s easy to make a mess of things.)
- dorfsmay 3y ago
  When I tried phones and tablets were positive for "any-pointer" (not good!). From my tests the most reliable way to check for a mouse/track point/track pad are (pointer: fine) and (not (hover: none). Personally, as a user, I don't like a menu that take the whole page when on a desktop, I find a top bar or a hamburger work much better, but those don't work with a small enough screen and without a pointer device (mobile devices), where a vertical menu with big buttons is more appropriate. But I'm not a UX specialist nor a designer, so this is what I suggest but obviously follow their specs.

kps 3y ago

Ironic that a brand new article about media queries doesn't use (or mention) prefers-color-scheme.