Dynamically scaling CSS values based on the viewport width is hardly a new topic. You can find plenty of in-depth coverage right here on CSS-Tricks in articles like this one or this one.
Most of those examples, though, use relative CSS units and unitless values to achieve fluid scaling. That loses pixel perfection and usually introduces text wrapping and layout shifts once the screen goes below or above a certain threshold.
But what if we really do want pixel perfection? What if, let’s say, we are developing a complex real-time analytics dashboard to be viewed on large TVs at a conference room or as some PWA to be opened exclusively on mobile and tablet devices, as opposed to text-heavy blogs and news websites? Those are cases where we need more precision.
In other words, what if we want to scale designs uniformly? Of course, one can scale
the content with CSS transforms based on the available width as covered in this article — this way, the correct ratios are preserved.
However, we can also achieve fluid proportional scaling UIs using pixel values in CSS. They scale appropriately based on the device screen real estate, all while preserving their pixel-perfect proportions. Further, we can still use pixel values and automatically convert them to relative CSS units if working in pixels is more comfortable or familiar.
Scaling our UI
Let’s try to implement this awesome dashboard, courtesy of Craftwork. We need to make it in such a way that it scales perfectly and preserves all the texts line counts, margins, image sizes, etc.

Let’s work in CSS pixel values and use SCSS for speed and convenience. So, if we are to target the title of one of these card widgets, our SCSS might look something like this:
.cardWidget {
.cardHeading {
font-size: 16px;
}
}
Nothin’ fancy. Nothing we have not seen before. Being a pixel value, this will not scale.
This design was created with a container that’s 1600px
wide. Let’s assume that at 1600px
, the ideal font size for the titles of the cards should be 16px
since that’s how it’s designed.
Now that we have the “ideal” container width font size for this width, let’s scale our CSS pixel values accordingly using the current* viewport width:
/*
1600px is the ideal viewport width that the UI designers who
created the dashboard used when designing their Figma artboards
Please not we are not using pixel units here, treating it purely
as a numeric value.
*/
--ideal-viewport-width: 1600;
/*
The actual width of the user device
*/
--current-viewport-width: 100vw;
.cardWidget {
.cardHeading {
/*
16px is the ideal font size that the UI designers want for
1600px viewport width.
Please note that we are not using pixel units here,
treating it purely as a numeric value.
*/
--ideal-font-size: 16;
/*
Calculate the actual font size:
We take our idealFontSize and multiply it by the difference
between the current viewport width and the ideal viewport width.
*/
font-size: calc(
var(--ideal-font-size) * (var(--current-viewport-width) / var(--ideal-viewport-width)
);
}
}
As you can see, we treat the ideal font size we obtained from the design as a base and multiply it by the difference between the current and ideal viewport widths. How does this look mathematically? Let’s say we are viewing this web app on a screen with the exact same width as the mockup:
--current-device-width: 100vw; // represents 1600px or full width of the screen
--ideal-viewport-width: 1600; // notice that the ideal and current width match
--ideal-font-size: 16;
// this evaluates to:
font-size: calc(16 * 1600px / 1600);
// same as:
font-size: calc(16 * 1px);
// final result:
font-size: 16px;
So, since our viewport width matches perfectly, our font-size
ends being exactly 16px
at the ideal viewport width of 1600px
.
As another example, let’s say we are viewing the web app on a smaller laptop screen that’s 1366px
wide. Here is the updated math:
font-size: calc(16 * 1366px / 1600);
// same as:
font-size: calc(16 * 0.85375px);
// final result:
font-size: 13.66px;
Or let’s say we are viewing this on a full high-definition display at 1920px
wide:
font-size: calc(16 * 1920px / 1600);
// same as:
font-size: calc(16 * 1.2px);
// final result:
font-size: 19.2px;
You can see for yourself how even though we use pixel values as reference, we are actually able to proportionally scale our CSS values based on the difference in width between the ideal and current viewport sizes.
Here is a small demo I built to illustrate the technique:
Here’s a video for convienence:
Clamping the min and max viewport width
Using this current approach, the design scales to match the viewport size, no matter how big or small the viewport gets. We can prevent this with CSS clamp()
which allows us to set a minimum width of 350px
and maximum width of 3840px
. This means that if we are to open the web app on a device with 5000px
width, our layout will stay locked at 3840px
:
--ideal-viewport-width: 1600;
--current-viewport-width: 100vw;
/*
Set our minimum and maximum allowed layout widths:
*/
--min-viewport-width: 350px;
--max-viewport-width: 3840px;
.cardWidget {
.cardHeading {
--ideal-font-size: 16;
font-size: calc(
/*
The clamp() function takes three comma separated expressions
as its parameter, in the order of minimum value, preferred value
and maximum value:
*/
--clamped-viewport-width: clamp(var(--min-viewport-width), var(--current-viewport-width), var(--max-viewport-width);
/*
Use the clamped viewport width in our calculation
*/
var(--ideal-font-size) * var(--clamped-viewport-width) / var(--ideal-viewport-width)
);
}
}
Let’s make a helper for the unit conversions
Our code is quite verbose. Let’s write a simple SCSS function that converts our values from pixels to relative units. That way, we can import and reuse anywhere this anywhere without so much duplication:
/*
Declare a SCSS function that takes a value to be scaled and
ideal viewport width:
*/
@function scaleValue(
$value,
$idealViewportWidth: 1600px,
$min: 350px,
$max: 3840px
) {
@return calc(
#{$value} * (clamp(#{$min}, 100vw, #{$max}) / #{$idealViewportWidth})
);
}
/*
We can then apply it on any numeric CSS value.
Please note we are passing not pixel based, but numeric values:
*/
.myElement {
width: #{scaleValue(500)};
height: #{scaleValue(500)};
box-shadow: #{scaleValue(2)} #{scaleValue(2)} rgba(black, 0.5);
font-size: #{scaleValue(24)};
}
Porting this to Javascript
Sometimes CSS doesn’t cut it and we have to use JavaScript to size a component. Let’s say we are constructing an SVG dynamically and we need to size its width
and height
properties based on an ideal design width. Here is the JavaScript to make it happen:
/*
Our helper method to scale a value based on the device width
*/
const scaleValue = (value, idealViewportWidth = 1600) => {
return value * (window.innerWidth / idealViewportWidth)
}
/*
Create a SVG element and set its width, height and viewbox properties
*/
const IDEAL_SVG_WIDTH = 512
const IDEAL_SVG_HEIGHT = 512
const svgEl = document.createElement('svg')
/* Scale the width and height */
svgEl.setAttribute('width', scaleValue(IDEAL_SVG_WIDTH))
svgEl.setAttribute('height', scaleValue(IDEAL_SVG_WIDTH))
/*
We don't really need to scale the viewBox property because it will
perfectly match the ratio of the scaled width and height
*/
svg.setAttribute('viewBox', `0 0 ${IDEAL_SVG_WIDTH} ${IDEAL_SVG_HEIGHT}`)
The drawbacks of this technique
This solution is not perfect. For example, one major drawback is that the the UIs are no longer zoomable. No matter how much the user zooms, the designs will stay locked as if they are viewed at 100% zoom.
That said, we can easily use traditional media queries, where we set different ideal numeric values at different viewport widths:
.myElement {
width: #{scaleValue(500)};
height: #{scaleValue(500)};
box-shadow: #{scaleValue(2)} #{scaleValue(2)} rgba(black, 0.5);
font-size: #{scaleValue(24)};
@media (min-width: 64em) {
width: #{scaleValue(800)};
font-size: #{scaleValue(42)};
}
}
Now we can benefit from both media queries and our pixel-perfect linear scaling.
Wrapping up
All of this is an alternative way to implement fluid UIs. We treat the pixel-perfect values as pure numeric values, and multiply them by the difference between the current viewport width and the “ideal” viewport width from the designs.
I have used this technique extensively in my own work and hope that you will find some use of it too.
You know it’s a great solution when you look at it and go, “damn, why didn’t I think of that?!”
Thanks a lot, really interesting approach.
What’s the performance of this technic? Are the values evaluated only once?
It is evaluated on each resize, i.e. when the numeric representation of
100vw
changes.All of the calculations are offloaded to CSS, so I would say it is pretty fast performance-wise.
Interesting! I wouldn’t have thought to use calc this way and I think the scaleValue function is elegant. Personally I tend to just use em units for everything and set the body’s font size to VW units. I’m not sure I see the drawbacks of my method… Can somebody enlighten me?
Hi Koen, I think the major drawback of using “fluid” units like em / vw is that you inevitably lose pixel perfection. You can get pretty close, but your layout will always shift / rearrange in certain resolutions.
This technique tries to minimise this problem and preserves the sizes in all kinds of different resolutions.
Do you mean that if I set the font size to 1rem on the root element, and make it scale with the viewport width, the design will not scale to a perfect pixel version at a resolution that you get from your design team? I disagree, but you don’t tell us how it loses “pixel perfection” so I can’t argue.
The above quote describe a difference as the result of a division:
I believe that a difference is the result of a substraction and that a quotient is the result of a division.
With this approach, texts tend to be ultra small on small screen and unreadable. I think it’s nice for diagrams and stuff like that, but not for overall page design.
Hi Raphael, we can mix this technique with media queries and make sure we use bigger values for smaller resolutions!
I agree. Forces the user to use your app in full screen. On desktop, if they resize the screen, it becomes unusable as shown in the video.
I love this!
At the end, you’re saying it would only be “zoomable” if using media queries?
Pretty Nice and elegant!
The only thing I would add here is maybe another argument that allows me to set min value returned by the function for eg. I might want a min font size value.
But that would mess with the overall look of the
widget
and I’d maybe even see some overflowing text in that scenario. Any suggestions if we proceed that way?Nice article and implementation, but my concerns are with font size and accessibility. Should we really be scaling the font size to maintain this Pixel Perfect look? What happens to readability?
I see to many CONS in using this.
Code becomes harder to maintain
css size increases in bigger scale projects
In smaller screens app would become unusable, for example in mobile resolution the design has too many changes in sizing of paddings, margins, fonts, etc. So you will need to write media queries with all this scale logic, which sometimes might become even harder to maintain.
Try to combine all these things: write a big-scale project that is usable on mobile, tablets and desktops, that has JS CSS handling.
I have been using a similar technique for quite a few months now, and I love that this article has finally validated my work.
Unlike the article though, I found it easier to use REM values instead of using calc() + SCSS functions.
The technique I use goes like this:
html { font-size: 1.6vw }
p { font-size: 1rem; } /* 16px */
div { width: 3.75rem } /* 60px */
There are kinks that I haven’t figured out yet, and there is an upgrade to this technique that I recently used where if the viewport is above 1680px, then I use absolute PX values, since a larger screen would equate to a larger design and that has consequences. Anything between 960-1440 I use scaled, so that I won’t have to use multiple media queries to make the layout look nicer on all screen sizes.
On Mobile and Tablet, I prefer to use Pixel values too!
While the idea here is pretty neat, I see several problems with this approach.
One problem is that it’s not true pixel-perfection because you’re losing precision from floating-point calculations. At certain viewport widths, your calculations are going to yield imprecise values that get rounded off/truncated, and thus the page looks slightly different than at other widths. For example, in the Codepen that you linked, if you shrink the page down to ~600px, the tags for some of the cards start to wrap to the next line. And if you resize the page slowly, you’ll notice that at certain viewport widths, the images become distorted and are wider than they are tall. The page jitters as you resize it, suggesting that it isn’t maintaining its proportions correctly.
The more obvious problem with this approach is that your font sizes are illegibly small. On a 360px mobile device, you’re going to get a tiny base font size of
3.6px
. You can use media queries to fix this, but then you’ve defeated the purpose of using this technique in the first place.On a related note, this disregards users’ font size preferences. On a
1600px
-wide device, users will always get a base font size of16px
, even if they’ve configured their browser to have a different root font size.Instead, I recommend using the 62.5% root font size trick together with a body font size of
1.6rem
. This allows you to think in pixels but code in responsive units that respect users’ font size preferences. You can even combine it with clamp to create fluid typography.The technique I use goes like this:
`html { font-size: 1.6vw }
p { font-size: 1rem; } /* 16px */
div { width: 3.75rem } /* 60px */`
There are kinks that I haven’t figured out yet, and there is an upgrade to this technique that I recently used where if the viewport is above 1680px, then I use absolute PX values, since a larger screen would equate to a larger design and that has consequences. Anything between 960-1440 I use scaled, so that I won’t have to use multiple media queries to make the layout look nicer on all screen sizes.
Nice one! But what if my viewport doesn’t scale but my container? I have by default one container div in a given viewport. But using JS I can toggle into view another two container divs. And within those divs I’d like to scale the text, which when 3 divs are shown side by side, would be smaller if only one container div was shown. No change in viewport, only in the relative size of the container div.
I have done this in the past, too but have found it doesn’t work well for accessibility. Text becomes smaller as you resize and becomes very hard to read. Something to keep in mind is that not everyone browses your website in full screen.
At which point, as you introduce media queries, this technique unfortunately requires more work to setup with no benefit in the end, as you’re already defining sizes at different scales.
There are some use-cases in this, such as isolated components which should respond to the size of the viewport and scale accordingly, but I would not do this for an entire site.
This is great, especially if you need a CSS only solution. But if you’re willing to use Javascript, I feel like it’s over complicated and easy to get not quite right (Notice in the example some things actually drop down lines because the scaling isn’t perfect).
I’ve done this codepen example that should be much simpler and likely far more maintainable and reliable without having the drawbacks mentioned.
Hope it helps someone!