4 ms·

I’ve found that a significant number of media queries can be replaced by fluid rules instead. E.g. instead of setting padding and full width on a container for

by jacobr 4y ago

I’ve found that a significant number of media queries can be replaced by fluid rules instead. E.g. instead of setting padding and full width on a container for mobile and a fixed width on desktop, do this for all breakpoints width: min(calc(100wv - 2rem), 80rem) Instead of resizing text for different breakpoints, use font-size: clamp(2rem, 4vw + 1rem, 3rem); etc. No media queries needed. I also find it easier to reason about since you don’t have different rules applying in different circumstances.

oblak 4y ago
I'd say you're on the right track. It's been years since I had to use media queries. Frankly, I associate them with bad job being done. Either due to inexperience or simply laziness
5350-uiop-1130 4y ago
seems interesting, but would be difficult to debug for me. prefer explicitness over conciseness.
- bryanrasmussen 4y ago
  min and max can be difficult to figure out, especially if they have a bunch of calculations and stuff going on, but clamp is generally more explicit a description of what is wanted than media queries, for example the clamp above says: never let the font size be smaller than 2rem never let the font size be bigger than 3rem the middle is then your fluid calculation of what the size should be between those two sizes. since min, max, and clamp can be used in every property that can use calc it follows that lots of media query code can be replaced. Finally when using media queries alone you will always run into some situation where something does not look that good if you are resizing your window and you are still in breakpoint 1 but you have not hit breakpoint 2 yet, you can of course fix that by adding a breakpoint in between these two, but the same problem presents itself multiple times. Media queries alone will never give a 100% fluid experience.
  - 5350-uiop-1130 4y ago
    interesting to know, thanks
deleted 4y ago
[deleted]
chrismorgan 4y ago
Note that the vw unit is broken by design because it includes the viewport scrollbar, so that 100vw may be more than 100% of the effective viewport width—100vw is always wrong. There are some situations where the imprecision is acceptable, but there are almost always better solutions these days.
- madeofpalk 4y ago
  I'm not sure exactly about how scrollbar width plays into it, but the Large/Small/Dynamic Viewport Units help out with this https://css-tricks.com/the-large-small-and-dynamic-viewports/ https://css-tricks.com/the-large-small-and-dynamic-viewports... Doesn't look like they're supported by Chrome yet, but they're there in Firefox and Safari.
  - chrismorgan 4y ago
    Those new viewport units only fix the issues with retractable chrome as commonly employed on mobile platforms. They completely ignored the scrollbars issue which has been a design bug from the very start (though there used to be a workaround—`overflow: scroll` on the body—but it was removed from the spec after only Firefox ever implemented it), which I cynically say is because it’s not an issue on mobile platforms which uniformly use overlay scrollbars.
- jacobr 4y ago
  I wouldn't say it's wrong in the examples above - I want to have the same padding on both sides, and not the padding + scrollbar gutters on one side. There's also `scrollbar-gutter: stable` to always reserve space for the scrollbar. It's not supported in Safari, but macOS uses overlay scrollbars by default anyway so it doesn't really matter.
  - chrismorgan 4y ago
    It’s wrong, because 100vw is the document width plus any scrollbar width (including via scrollbar-gutter). If you have a body with zero padding and a vertical scrollbar, then 100vw > 100% except on platforms with overlay scrollbars. On Windows, this is likely to mean that or a 1000px-wide body, 100vw will be 1017px.
mematic 4y ago
I use a similar approach with linear mapping to gain known boundaries. body { --scrollbar-width: 0px; --320-to-1440: ( 100vw - ( 320px + var( --scrollbar-width ) ) ) / 1120; } h1 { font-size: clamp( 20px, calc( 20px + var( --320-to-1440 ) * 10 ), 30px ); } While accounting for the scrollbar width via JavaScript. document.body.style.setProperty( '--scrollbar-width', `${ window.innerWidth - document.documentElement.clientWidth }px` ); This will be easier when user-defined functions arrive.

by jacobr 4y ago

oblak 4y ago

I'd say you're on the right track. It's been years since I had to use media queries. Frankly, I associate them with bad job being done. Either due to inexperience or simply laziness

5350-uiop-1130 4y ago

seems interesting, but would be difficult to debug for me. prefer explicitness over conciseness.

bryanrasmussen 4y ago
min and max can be difficult to figure out, especially if they have a bunch of calculations and stuff going on, but clamp is generally more explicit a description of what is wanted than media queries, for example the clamp above says: never let the font size be smaller than 2rem never let the font size be bigger than 3rem the middle is then your fluid calculation of what the size should be between those two sizes. since min, max, and clamp can be used in every property that can use calc it follows that lots of media query code can be replaced. Finally when using media queries alone you will always run into some situation where something does not look that good if you are resizing your window and you are still in breakpoint 1 but you have not hit breakpoint 2 yet, you can of course fix that by adding a breakpoint in between these two, but the same problem presents itself multiple times. Media queries alone will never give a 100% fluid experience.
- 5350-uiop-1130 4y ago
  interesting to know, thanks

deleted 4y ago

[deleted]

chrismorgan 4y ago

Note that the vw unit is broken by design because it includes the viewport scrollbar, so that 100vw may be more than 100% of the effective viewport width—100vw is always wrong. There are some situations where the imprecision is acceptable, but there are almost always better solutions these days.

madeofpalk 4y ago
I'm not sure exactly about how scrollbar width plays into it, but the Large/Small/Dynamic Viewport Units help out with this https://css-tricks.com/the-large-small-and-dynamic-viewports/ https://css-tricks.com/the-large-small-and-dynamic-viewports... Doesn't look like they're supported by Chrome yet, but they're there in Firefox and Safari.
- chrismorgan 4y ago
  Those new viewport units only fix the issues with retractable chrome as commonly employed on mobile platforms. They completely ignored the scrollbars issue which has been a design bug from the very start (though there used to be a workaround—`overflow: scroll` on the body—but it was removed from the spec after only Firefox ever implemented it), which I cynically say is because it’s not an issue on mobile platforms which uniformly use overlay scrollbars.
jacobr 4y ago
I wouldn't say it's wrong in the examples above - I want to have the same padding on both sides, and not the padding + scrollbar gutters on one side. There's also `scrollbar-gutter: stable` to always reserve space for the scrollbar. It's not supported in Safari, but macOS uses overlay scrollbars by default anyway so it doesn't really matter.
- chrismorgan 4y ago
  It’s wrong, because 100vw is the document width plus any scrollbar width (including via scrollbar-gutter). If you have a body with zero padding and a vertical scrollbar, then 100vw > 100% except on platforms with overlay scrollbars. On Windows, this is likely to mean that or a 1000px-wide body, 100vw will be 1017px.

mematic 4y ago

I use a similar approach with linear mapping to gain known boundaries. body { --scrollbar-width: 0px; --320-to-1440: ( 100vw - ( 320px + var( --scrollbar-width ) ) ) / 1120; } h1 { font-size: clamp( 20px, calc( 20px + var( --320-to-1440 ) * 10 ), 30px ); } While accounting for the scrollbar width via JavaScript. document.body.style.setProperty( '--scrollbar-width', `${ window.innerWidth - document.documentElement.clientWidth }px` ); This will be easier when user-defined functions arrive.