Menu Search
Jump to the content X X
Design Systems book

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books such as Design Systems, a book dedicated to creating design systems and pattern libraries? Check the table of contents →

Fluid Responsive Typography With CSS Poly Fluid Sizing

Fluid layouts have been a normal part of front-end development for years. The idea of fluid typography, however, is relatively new and has yet to be fully explored. Up until now, most developers’ idea of fluid typography is simply using Viewport units maybe with some minimum and maximum sizes.

In this article, we are going to take it to another level. We are going to examine how to create scalable, fluid typography across multiple breakpoints and predefined font sizes using well-supported browser features and some basic algebra. The best part is that you can automate it all by using Sass.

Further Reading on SmashingMag: Link

When working with creative designers on web page designs, it’s fairly common to receive multiple Sketch or Photoshop artboards/layouts, one for each breakpoint. In that design, elements (like an h1 heading) will usually be different sizes at each breakpoint. For example:

  1. The h1 at the small layout could be 22px
  2. The h1 at the medium layout could be 24px
  3. The h1 at the large layout could be 34px

The bare minimum CSS for this uses media queries5:

h1 {
  font-size: 22px;
@media (min-width:576px) {
  h1 {
    font-size: 22px;
@media (min-width:768px) {
  h1 {
    font-size: 24px;
@media (min-width:992px) {
  h1 {
    font-size: 34px;

This is a good first step, but you are limiting the font-size to only what was specified by the designer at the provided breakpoints. What would the designer say if you asked, “What should the font-size be at an 850px wide viewport?” The answer in most cases is that it would be somewhere between 24px and 34px. But right now, it’s just 24px according to your CSS, which is probably not what the designer was envisioning.

Your option at this point is to calculate what that size should be and add another breakpoint. That’s easy enough. But what about all the other resolutions? What should the font-size be at 800px wide? What about 900px? What about 935px? Obviously the designer is not going to provide you with a full layout for every single possible resolution. Even if they did, should you be adding dozens (or hundreds) of breakpoints for all the different font-sizes that are desired by the designer? Of course not.

Your layout is already fluidly scaling with the width of your viewport. Wouldn’t it be nice if your typography predictably scaled with your fluid layout? What else can we do to improve upon this?

Viewport Units To The Rescue? Link

Viewport units7 are another step in the right direction. They allow your text to fluidly resize with your layouts. And the browser support8 is great these days.

Can I Use Viewport?9
(View large version10)

But the viability of Viewport units is very dependent on the original creative designs for a web page. It would be great to just set your font-size using vw and be done:

h1 {
  font-size: 2vw;

But this only works if your creative art-boards take this into account. Did the designer choose a text size that was exactly 2% of the width of each of his art-boards? Of course not. Let’s calculate what the vw value would need to be for each of our breakpoints:

22px size @ 576px wide = 22/576*100 = 3.82vw
24px size @ 768px wide = 24/768*100 = 3.13vw
34px size @ 992px wide = 34/992*100 = 3.43vw

They are close but they aren’t all the same. So you would still need to use media queries to transition between text sizes and there would still be jumps. And consider this weird side-effect:

@ 767px, 3.82% of the viewport width is 29px. If the viewport is 1-pixel wider the font-size sudden drops back down to 24px. This animation of a viewport being resized demonstrates this undesirable side effect:


This dramatic change in font-size is almost definitely not what the designer was envisioning. So how do we solve this problem?

Statistical Linear Regression? Link

Wait. What? Yes, this is an article about CSS, but some basic math can go a long way towards an elegant solution to our problem.

First, lets plot our resolutions and corresponding text sizes on a graph:

Scatter plot of font-size and corresponding Viewport width13
Scatter plot of font-size and corresponding Viewport width (Google Spreadsheets) (View large version14)

Here you can see a scatter plot of the designer’s specified text sizes at the defined viewport widths. The x-axis is the viewport width and the y-axis is the font-size. See that line? That’s called a trendline. It’s a way to find an interpolated font-size value for any viewport width, based on the data provided.

The Trendline Is The Key To All Of This Link

If you could set your font-size according to this trendline, you would have an h1 that smoothly scales on all resolutions that would come close to matching what the designer intended. First, let’s look at the math. The straight line is defined by this equation:

Linear equation definition
Linear equation definition
  • m = slope
  • b = the y-intercept
  • x = the current viewport width
  • y = the resulting font-size

The are several methods for determining the slope and y-intercept. When multiple values are involved, a common method is the Least Squares15 fit:

Least Squares

Once you run those calculations, you have your trendline equation.

How Do I Use This In CSS? Link

Okay, this is getting pretty heavy on the math. How do we actually use this stuff in front-end web development? The answer is CSS calc()! Once again, a fairly new CSS technology that is very well supported16.

Can I Use Calc?17
(View large version18)

You can use the trendline equation like this:

h1 {
  font-size: calc({slope}*100vw + {y-intercept}px);

Once you find your slope and y-intercept you just plug them in!

Note: You have to multiply the slope by 100 since you are using it as a vw unit which is 1/100th of the Viewport width.

Can This Be Automated? Link

I ported the least squares fit method into an easy-to-use Sass function:

/// least-squares-fit
/// Calculate the least square fit linear regression of provided values
/// @param {map} $map - A Sass map of viewport width and size value combinations
/// @return Linear equation as a calc() function
/// @example
///   font-size: least-squares-fit((576px: 24px, 768px: 24px, 992px: 34px));
/// @author Jake Wilson <>
@function least-squares-fit($map) {
  // Get the number of provided breakpoints
  $length: length(map-keys($map));
  // Error if the number of breakpoints is < 2
  @if ($length < 2) {
    @error "leastSquaresFit() $map must be at least 2 values"
  // Calculate the Means
  $resTotal: 0;
  $valueTotal: 0;
  @each $res, $value in $map {
    $resTotal: $resTotal + $res;
    $valueTotal: $valueTotal + $value;
  $resMean: $resTotal/$length;
  $valueMean: $valueTotal/$length;

  // Calculate some other stuff
  $multipliedDiff: 0;
  $squaredDiff: 0;
  @each $res, $value in $map {
    // Differences from means
    $resDiff: $res - $resMean;
    $valueDiff: $value - $valueMean;
    // Sum of multiplied differences
    $multipliedDiff: $multipliedDiff + ($resDiff * $valueDiff);
    // Sum of squared resolution differences
    $squaredDiff: $squaredDiff + ($resDiff * $resDiff);

  // Calculate the Slope
  $m: $multipliedDiff / $squaredDiff;

  // Calculate the Y-Intercept
  $b: $valueMean - ($m * $resMean);

  // Return the CSS calc equation
  @return calc(#{$m*100}vw + #{$b});


Does this really work? Open up this CodePen19 and resize your browser window. It works! The font sizes are fairly close to what the original design was asking for and they smoothly scale with your layout.

Least Squares Fit SCSS test user=”jakobud”]See the Pen Least Squares Fit SCSS test20 by Jake Wilson (@jakobud3521) on CodePen3622.

Least Squares Fit SCSS test

Now, admittedly, it’s not perfect. The values are close to the original design but they do not quite match up. This is because a linear trendline is an approximation of specific font sizes at specific viewport widths. This is inherit of linear regression. There is always some error in your results. It’s a trade-off of simplicity vs. accuracy. Also, keep in mind, the more varied your text sizes are, the more error there will be in your trendline.

Can we do better than this?

Polynomial Least Squares Fit Link

In order to get a more accurate trendline, you need to look at more advanced topics, like a polynomial regression23 trendline that might look something like this:

Polynomial regression trendline24
Polynomial regression trendline (Google Spreadsheets) (View large version25)

Now that is more like it! Much more accurate than our straight line. A basic polynomial regression equation looks like this:

A 3rd degree polynomial equation
A 3rd degree polynomial equation

The more accurate you want your curve, the more complicated the equation gets. Unfortunately, you can’t do this in CSS. calc() simply cannot do this type of advanced math. Specifically, you can’t calculate exponents:

font-size: calc(3vw * 3vw); /* This doesn’t work in CSS */

So until calc() supports this type of non-linear math, we are stuck with linear equations only. Is there anything else we can do to improve upon this?

Breakpoints And Multiple Linear Equations Link

What if we were only calculating a straight line between each pair of breakpoints? Something like this:

Linear Regression trendlines between multiple pairs of values26
Linear Regression trendlines between multiple pairs of values (Google Spreadsheets) (View large version27)

So in this example we would calculate the straight line between 22px and 24px and then another between 24px and 34px. The Sass would look like this:

h1 {
  @media (min-width:576px) {
    font-size: calc(???);
  @media (min-width:768px) {
    font-size: calc(???);

We could use the least squares fit method for those calc() values but since it’s just a straight line between 2 points, the math could be greatly simplified. Remember the equation for a straight line?

Linear equation definition
Linear equation definition

Since we are talking about just 2 points now, finding the slope (m) and y-intercept (b) is trivial:

 Finding the slope and y-intercept of a linear equation
Finding the slope and y-intercept of a linear equation

Here is a Sass function for this:

/// linear-interpolation
/// Calculate the definition of a line between two points
/// @param $map - A Sass map of viewport widths and size value pairs
/// @returns A linear equation as a calc() function
/// @example
///   font-size: linear-interpolation((320px: 18px, 768px: 26px));
/// @author Jake Wilson <>
@function linear-interpolation($map) {
  $keys: map-keys($map);
  @if (length($keys) != 2) {
    @error "linear-interpolation() $map must be exactly 2 values";
  // The slope
  $m: (map-get($map, nth($keys, 2)) - map-get($map, nth($keys, 1)))/(nth($keys, 2) - nth($keys,1));
  // The y-intercept
  $b: map-get($map, nth($keys, 1)) - $m * nth($keys, 1);
  // Determine if the sign should be positive or negative
  $sign: "+";
  @if ($b < 0) {
    $sign: "-";
    $b: abs($b);
  @return calc(#{$m*100}vw #{$sign} #{$b});

Now, just use the linear interpolation function on multiple breakpoints in your Sass. Also, lets throw in some min and max font-sizes:

h1 {
  // Minimum font-size
  font-size: 22px;
  // Font-size between 576 - 768
  @media (min-width:576px) {
    $map: (576px: 22px, 768px: 24px);
    font-size: linear-interpolation($map);
  // Font-size between 768 - 992
  @media (min-width:768px) {
    $map: (768px: 24px, 992px: 34px);
    font-size: linear-interpolation($map);
  // Maximum font-size
  @media (min-width:992px) {
    font-size: 34px;

And it generates this CSS:

h1 {
  font-size: 22px;
@media (min-width: 576px) {
  h1 {
    font-size: calc(1.04166667vw + 16px);
@media (min-width: 768px) {
  h1 {
    font-size: calc(4.46428571vw - 10.28571429px);
@media (min-width: 992px) {
  h1 {
    font-size: 34px;

The Holy Grail Of CSS Sizing? Link

Lets wrap this all up in a nice Sass mixin (for the lazy and efficient!). I’m coining this method Poly Fluid Sizing:

/// poly-fluid-sizing
/// Generate linear interpolated size values through multiple break points
/// @param $property - A string CSS property name
/// @param $map - A Sass map of viewport unit and size value pairs
/// @requires function linear-interpolation
/// @requires function map-sort
/// @example
///   @include poly-fluid-sizing('font-size', (576px: 22px, 768px: 24px, 992px: 34px));
/// @author Jake Wilson <>
@mixin poly-fluid-sizing($property, $map) {
  // Get the number of provided breakpoints
  $length: length(map-keys($map));
  // Error if the number of breakpoints is < 2
  @if ($length < 2) {
    @error "poly-fluid-sizing() $map requires at least values"

  // Sort the map by viewport width (key)
  $map: map-sort($map);
  $keys: map-keys($map);

  // Minimum size
  #{$property}: map-get($map, nth($keys,1));
  // Interpolated size through breakpoints
  @for $i from 1 through ($length - 1) {
    @media (min-width:nth($keys,$i)) {
      $value1: map-get($map, nth($keys,$i));
      $value2: map-get($map, nth($keys,($i + 1)));
      // If values are not equal, perform linear interpolation
      @if ($value1 != $value2) {
        #{$property}: linear-interpolation((nth($keys,$i): $value1, nth($keys,($i+1)): $value2));
      } @else {
        #{$property}: $value1;
  // Maxmimum size
  @media (min-width:nth($keys,$length)) {
    #{$property}: map-get($map, nth($keys,$length));

This Sass mixin requires a few Sass functions in the following Github gists:

The poly-fluid-sizing() mixin will perform linear interpolation on each pair of viewport widths and set a minimum and maximum size. You can import this into any Sass project and easily utilize it without needing to know any of the math behind it. Here is the final CodePen33 that uses this method.

Poly Fluid Sizing using linear equations, viewport units and calc() user=”jakobud”]See the Pen Poly Fluid Sizing using linear equations, viewport units and calc()”] Poly Fluid Sizing using linear equations, viewport units and calc()34 by Jake Wilson (@jakobud3521) on CodePen3622.

Poly Fluid Sizing using linear equations, viewport units and calc()

A Few Notes Link

  • Obviously this method applies not only to font-size but to any unit/length property (margin, padding, etc). You pass the desired property name into the mixin as a string.
  • The Sass map of viewport width + size value pairs can be passed in any order into the poly-fluid-sizing() mixin. It will automatically sort the map according to Viewport width from lowest to highest. So you could pass in a map like this and it would work out just fine:
  $map: (576px: 22px, 320px: 18px, 992px: 34px, 768px: 24px);
  @include poly-fluid-sizing('font-size', $map);
  • A limitation for this method is that you cannot pass in mixed units into the mixin. For example, 3em @ 576px width. Sass just won’t really know what to do mathematically there.

Conclusion Link

Is this the best we can do? Is Poly Fluid Sizing the Holy Grail of fluid unit sizing in CSS? Maybe. CSS currently supports non-linear animation37 and transition38 timing functions, so maybe there is a chance39 that calc() will also support it someday. If that happens, non-linear, polynomial regression might be worth a look again. But maybe not… Linear scaling might be superior anyways.

I began exploring this idea40 in early 2017 and eventually developed the above solution. Since then, I’ve seen a few dev’s come up with similar ideas and different pieces of this puzzle. I thought it was time for me to share my method and how I got there. Viewport units. Calc(). Sass. Breakpoints. None of these things are new. They are all browser features that have existing for years (with varying degrees of support). I’ve only used them together in a way that hadn’t been fully explored yet. Don’t ever be afraid to look at the tools you use every day and think out-of-the-box on how you can utilize them better and grow your skill set.

(vf, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40

↑ Back to top Tweet itShare on Facebook

Software Developer, husband and father of three

  1. 1

    This is all good and well, but what user (minus the devs/designers) are going to actually scale the browser up and down? I think its a great solution but I don’t think the reason you gave it is the reason it should be used. Thanks!

    • 2

      Jake Wilson

      May 15, 2017 7:49 pm

      Thank you for the feedback, Jordan. I touched on this with some of the other comments below, but the purpose of this method is not to watch your typography fluidly scale as you resize your browser (which yes, only dev’s are doing), but rather so that your typography is predictably scaled with your layout no matter which viewport size your audience is using. Seeing your typography scale as you resize your browser is simply a demonstration of the effectiveness of the method itself. Thank you again!

      • 3

        So on a smll device a i have a mess of small characters. This can be a solution for multi-large devices.. you have to optimize the layout and typo, not scale down every text :)

  2. 4

    This is pretty cool but it begs the question: Do you really need continuously responsive font size? What market segment are you putting off by not implementing something like this?

    • 5

      I read once that NOBODY resizes their browser windows, except for designers/devs.

      • 6

        I feel like if you use two differently sized monitors, you’re going to end up resizing your browser windows. That said, I doubt that you’d resize the browser window so thin as to trigger the need for the text to resize.

      • 7

        Jake Wilson

        May 15, 2017 6:18 pm

        Thank you for the feedback, Elise. You are absolutely right: The only people sitting there resizing browsers are web devs. But that isn’t the point of fluid typography. The idea behind it is that you can fully expect your typography to be predictably scaled relative to your layout no matter which viewport size your audience views your webpage in. If someone views it in mobile, it will be sized accordingly. Large desktop? No problem. iPad? No problem. Some random resolution in-between? No problem. Your typography will be scaled fluidly along with your layout no matter which resolution/viewport size the page is viewed at. Watching typography fluidly scale as you resize your browser is simply a nice side-effect and demonstration of the method in action. Thanks again!

    • 8

      I asked the same question and my question got removed…

    • 9

      Jason Williams

      May 15, 2017 5:40 pm

      I tend to agree. While I did read the whole article and I really think it’s a great idea I still wonder how many web viewers will benefit. When most people view a page they will view it on a single device and they probably won’t be scaling the window size.

    • 10

      Jake Wilson

      May 15, 2017 6:27 pm

      Thanks for the feedback, Ouroborus! There are many creative decisions to a webpage that you can ask whether or not you really need it. And this is simply another creative decision. Lets say a designer hands you a 400px wide layout with a font-size of 20px and a 800px wide layout with a font-size of 30px. If you asked the designer “What should the font size be at 600px?” what do you think the designer will say? Probably 25px since it’s right in-between the 2 font sizes right? What about at 500px? 700px? 735px? See what I’m getting at? This method simply interpolates the desired font-sizes between multiple breakpoints so that it will smoothly scale with your fluid layout. But like I said, it’s just a creative decision. Thanks again for the feedback!

      • 11

        Just optimize the text when it need to change… Is all about proportions, not about a specific font-size.

  3. 12

    Thanks… great review…. just FYI… the last codepen example doesn’t come across very useful only because resizing browser throws the pen completely off the screen and trying to use it means that you’ve got to chase the thing all over loosing the effectiveness of being able to compare the change. ???better to resize the pen at the same location on the page???

  4. 13

    Patrick Sullivan

    May 15, 2017 5:55 pm

    Cool idea. One of our devs tackled the same problem a bit ago, and released a node module for it here: Similarly, you can create a couple breakpoints, and cap the scaling at a minimum and maximum size. Thoughts/comments appreciated.

  5. 14

    Henk C. Meerhof

    May 15, 2017 6:44 pm

    This is a nice example of how to fluently scale parts of a site according to a device and/or viewport.

    The question in typography, however, is NOT how large the type is presented referring to the carrier of that type (paper, screen, building wall or whatever the type is on).
    The question is how large the type is – or has to be – referring to the viewing distance between the carrier surface and the reader!
    It makes no sense to scale a h1 up to 1500 pica pt or have normal text at x-height 50 mm on a large screen if this screen is mainly to be read from about 1 meter distance. In fact there should be no difference at all between different devices when they are simultaneous viewed from the same distance!

    • 15

      Kevin Nicasi

      May 16, 2017 10:54 am

      Agreed. A good designer takes all this into account when making mockups. That’s why the font size is usually scalled down for smaller devices, those are usually held closer.

      Mr Wilson provides an interesting technique here for a consistent experience.

      If you consider the last graph in the article, where this graph might fail is for really big desktop screens (I guess that’s what you’re talking about). When those big screens are used from a typical desktop viewing distance one could argue the font size shouldn’t scale up anymore after a certain screen width. A solution would be to have a horizontal line in the graph after a certain breakpoint. The graph would be a kind of a squashed s-curve then.

      • 16

        Jake Wilson

        May 16, 2017 3:32 pm

        Thanks for the feedback, Kevin. If you look closer at the final Sass mixin, you’ll see that it also outputs a maximum font-size (or whatever CSS property you are using) at the highest specified viewport width. This keeps the font-size from scaling infinitely. Similarly, it outputs a minimum font-size as well. It doesn’t exactly what you are suggesting regarding the squashed s-curve. Thanks,

  6. 17

    Using viewport units really hurts accessibility because the user can’t change the text size (some people need to do this to read content properly). As fancy and well though out as this is technique is I wouldn’t recommend using it.

    • 18

      Kevin Nicasi

      May 16, 2017 10:57 am

      Do you have any reference for this? If i change the zoom level in chrome the font size seems to scale just fine.

      • 19

        I’m not seeing this on my end and it seems odd that it would scale viewport units. By definition a viewport unit is relative to the viewport size, meaning if the viewport size doesn’t change then the font size doesn’t either. Maybe it’s a browser bug?

    • 20

      Ricky Onsman

      May 17, 2017 1:00 pm

      Not necessarily. See Accessible viewport units at

      • 21

        That’s not really a real world example of how most people would use viewport units, since it’s so subtle and not worth the effort in most cases. Unless you have a subtle thing like this then it’s still not accessible.

  7. 22
    	screen and (min-width: 64em) {
    		html {
    	 		font-size: calc(0.875em + 0.375 * (100vw - 64em) / 56); /* 1 */
    			font-size: -webkit-calc(87.5% + 0.375 * (100vw - 6400%) / 56); /* 2 */
    			font-size: -ms-calc(0.875em + 0.375 * (100vw - 64em) / 56); /* 3 */
    	screen and (min-width: 120.2em) {
    		html {
    	    	font-size: 1.375em;
    	only screen and (-webkit-min-device-pixel-ratio: 1.3) and (min-width:961px),
    	only screen and (-o-min-device-pixel-ratio: 13/10) and (min-width:961px),
    	only screen and (min-resolution: 120dpi) and (min-width:961px)
    		html {
    			font-size: 200%;

    I’ve been using this and rem sizes for all elements with success.

    • 23


      May 16, 2017 9:13 pm

      There is no -ms-calc and your calc and -webkit-calc styles need to be reversed.

  8. 24

    Rick Gregory

    May 16, 2017 5:10 am

    Very cool. Oddly, though, it’s not working on Safari Version 10.1 (12603. I’ll play with it some more and see if I can figure out what’s up.

    @others – folks, if you don’t see a use for it, don’t use it. However, you != the world.

  9. 26

    Peter Devine

    May 16, 2017 10:38 am

    I am very interested in this. It tallies with some articles I have read on modular scale (ratios) and addresses the problem of needing to create multiple typographic approaches for a singular typographic expression. I guess the next step is to address the accessibility issues. – thanks!

  10. 27

    Interesting, but I have one, big concern. This attempt will ruin my vertical rhythm (built with a tool like I tend to apply vertical rhythm not only to text but also to all the elements on my page.

    So in order not to break the rhythm I would have to apply vh/vw units to all the elements.

  11. 28

    Nothing of this is new. meh.

  12. 29

    This looks great, thanks.

    Do you have a licence for the mixins?

    I would like to wrap this up in an npm module to make it easy to add to projects.

  13. 30

    I only read a few of these comments, but they’re mostly the same. People are really missing the whole point behind this. Think of it as a way for you to design a website once and have it be sort of “future proof.” At least for typography any way. Just think about how many times you’ve upgraded your phone in the past decade. Resolutions change as new devices come out. With how fast technology changes nowadays, we as web designers/developers need to come up with solutions that let our designs look the way we want in any size window and on any size device. I would probably only use this for typography for now, because that means I can figure out how I want the type to look on mobile and on desktop and let this code do the magic for everything else in between.

    I first read about this “fluid type” concept back in 2015 from Being able to calculate the font-size and line-height is magical, in my opinion. Good work :)

    • 31

      Jake Wilson

      May 17, 2017 11:39 pm

      Thanks for the reply. Several readers do seem to get tripped up on thinking that this is only interesting/useful if you sit there and resize your browser window, which of course only developers do. They miss the point of the method, in that it ensures your typography (or whatever CSS property you are applying this to) will be linearly (and predictably) scaled at any resolution depending solely on your specified viewport and size combinations. Thanks again,

      • 32

        Jake, the reason several readers come to that conclusion is in part due to your own language:

        “This is a good first step, but it’s a little bit jolting when you resize your browser window. At each breakpoint, the text size instantly jumps up/down in size. It would be great if the resizing of fonts between layouts was completely fluid. You could throw in a CSS transition to smooth out that jump:”

        Resize browser window. Animation to smooth between jumps, and this is at the very beginning of the article, implying that this is the problem you’re trying to solve. A careful reader will find out that this isn’t really the point of the solution, but you do have a somewhat misleading start.

        PS: I wonder what you think about some web fonts being optimized to look best at fixed font sizes?

        • 33

          Jake Wilson

          May 19, 2017 7:22 am

          That is great feedback thanks. You are right. Some of my choices of words near the beginning does imply that it is the problem I am trying to solve. I will work on updating the article to be a little bit more concise in this area. Thank you!

        • 34

          Jake Wilson

          May 19, 2017 6:25 pm

          Hi Ferdy, I just wanted to let you know that I made some revision edits to the article around the area of resizing your browser and more towards the idea of linearly scaling your font-sizes so they are scaled appropriately at all viewport widths. Hopefully the problem is better defined now. Thanks again for the valuable feedback!

  14. 35

    Rafael Trinidad

    May 18, 2017 2:09 am

    This post gave me a nergasm. It was just full of geeketry and mathyness. Loved it.

  15. 36

    My postcss plugin this make easy in the box. But i don’t have english manual. If someone helps me translate the documentation and “how to use” article, I will be grateful.

  16. 37

    Something that is very similar to this by Indrek Paas:

  17. 38

    I really like the idea of fluid type. I feel it causes some weird breakpoints to look generally better (especially when combined with fluid spacing).

    My main concern though is performance impact, both the calcs rendering the page (battery life and general browser performance) and sass compilation with some pretty complex functions and calculations. especially on font-size which is a pretty commonly used property. Not to mention overall output size of compiled CSS (hoepfully fairly well compressed.. though)

    Does anyone have any feedback/experience/benchmarks on browser/dev performance of these techniques?

  18. 39

    Do you multiply `m` by `100vw` (as in saying X = 100vh) or do you multiply by 100 to make the value of `m` compatible with VW? namely, a percentage value it expects. Semantically, it’s slightly confusing.

  19. 40

    Love this article, I have been struggling with this for a couple weeks now and have come across very little in the way of informative methodology such as this.

    How would you say the final Holy Grail method compares to something like

    font-size: calc([minimum size] + ([maximum size] - [minimum size]) * ((100vw - [minimum viewport width]) / ([maximum viewport width] - [minimum viewport width])));

  20. 41

    Hey guys new question,

    How would you introduce this linear interpolation that listened to a ratio between the viewport width and height as well.

    Currently this method works beautifully for width resizing, but not for height, especially not both at the same time.

  21. 42

    to everyone who contributed in the comment section and of course, to jake wilson the author. thank you all very much.

  22. 43

    This is simply amazing. I have been up to my eyeballs learning flexbox and other elements of responsive design, so I actually came looking for this – an API or something to bring your typography along for the ride. Why wouldn’t you want the same measure of control you have over your other elements. It makes perfect sense to me. I am baffled by the early responses from people that cannot see the purpose, I wonder if they just wish they had thought of it first. Whatever. I resize my browser windows all the time! I don’t have the luxury of multiple monitors, so sometimes I have to share space on one screen. Besides, it’s not about self-entertainment, you morons, it’s about PREDICTABILITY, and devices come in every imaginable size.

    Jake, here is some unsolicited advice: Ignore any criticism that isn’t constructive or helpful. You don’t owe anybody an explanation; your work stands on its own merit.

    • 44

      I couldn’t agree more. This article blew my mind and I am fairly experienced with CSS. There have been many javascript solutions to tackle this issue and this article makes the best sense out of all other solutions. Whether you need to implement it in a project or not, that is beside the point and I don’t know why everyone above is arguing Jake on the merits of this technology. I think this solution is genius and well thought through! Thank you.


↑ Back to top