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.

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...

Doesn't look like they're supported by Chrome yet, but they're there in Firefox and Safari.

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.

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.

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.

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.

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

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.

interesting to know, thanks

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