Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

Truly Fluid Typography With vh And vw Units

Embracing fluid typography might be easier than you think. It has wide browser support, is simple to implement and can be achieved without losing control over many important aspects of design.

Unlike responsive typography1, which changes only at set breakpoints, fluid typography resizes smoothly to match any device width. It is an intuitive option for a web in which we have a practically infinite number of screen sizes to support. Yet, for some reason, it is still used far less than responsive techniques.

This might be because typography is so deeply rooted in the centuries-old history of typesetting. The concept of having “fluid” anything is often at odds with this tradition. In print, dimensions have always been fixed, but they don’t need to be on the web. That’s why I think fluid typography is a perfect match for the web. It’s a different approach for a completely different medium.

This doesn’t mean we need to throw out all conventions and everything we know about typography. We just need to learn how to apply the techniques we know in a slightly different way. Careful attention to detail will ensure we still have a perfectly crafted experience at all screen sizes.

Getting Started With Fluid Typography Link

Viewport units are what make fluid typography on the web possible. Viewport units refer to a percentage of the browser’s viewport dimensions. For example, 1 viewport width (vw) is equal to 1% of the viewport’s width. The units differ from percentages because they are always relative to the viewport, whereas a percentage is relative to the element’s parent container.

This means that, unlike all other unit types, viewport units are not in any way related to the base font size. This difference is significant and makes the units interesting and unique.

Four viewport units are available to us:

  • vw: viewport width
  • vh: viewport height
  • vmin: the smaller value of the viewport’s width and height
  • vmax: the larger value of the viewport’s width and height

The easiest way to start using fluid typography is to set the font-size on the html element to be a fluid unit:

html { font-size: 2vw; }

In this example, we’ve set the root element to 2vw. Therefore, we have changed the “root em.” Because all em and rem units are either directly or indirectly related to the root em, they will now also be fluid. For example:

h1 { font-size: 2em; }

A heading size of 2em is now equivalent to 4vw because this is twice the current font size of 2vw.

Using viewport-relative units alone comes with some drawbacks. We don’t get precise control over the rate of scale; we don’t have min or max font sizes; and, just like pixels, a declaration might override the user’s font-size preferences. Luckily, there are ways to overcome all of these limitations.

Controlling Viewport Units To Get Minimum And Maximum Font Sizes Link

Sticking 2vw on the html element, seeing that everything is fluid and calling it a day is easy, but it wouldn’t yield the best result. Viewport units are a blunt instrument and require some additional effort to get a workable result.

Because viewport units are always relative to the viewport, on very small screens, you could end up with ridiculously small font sizes.

Ideally, we’d be able to set a minimum font size, but we don’t yet have min-font-size property in CSS. With a little lateral thinking, though, we can achieve the same result in a few different ways.

First, we could use a calc() expression:

html { font-size: calc(1em + 1vw); }

In this example, at a viewport width of 0, the font-size would be exactly 1em. As the screen gets larger, the value of 1vw would be added to the minimum font size of 1em. But this technique is not always ideal; often we want to set a minimum font size at a screen size other than zero. We can handle this using media queries:

@media screen and (min-width: 50em) {
  html {
    font-size: 2vw;
  }
}

In this example, the font size would become fluid once the viewport reaches a width of 50 ems. This works really well, but it usually means a jump between the fixed and fluid values. To eliminate this, we can work out the precise point at which the fluid value matches the fixed value and set a breakpoint at that viewport size.

If the default font size is 16 pixels and if 2vw is 2% of the viewport’s width, then the calculation for working out the breakpoint would be 16 ÷ (2 ÷ 100). This gives us 800 pixels.

Because we want to use em units for our media queries, let’s convert the pixels to ems. We’ll divide 800 by 16 (or whatever the root em is equal to in pixels): 800 ÷ 16 = 50. If you find it easier, we could do the calculation in ems: 1 ÷ (2 ÷ 100) = 50. As you can see in the example above, by setting a font size of 2vw and a breakpoint of 50em, we get a seamless transition between the fixed and fluid values.

We can use the same calculation to work out a maximum font size. If we wanted a maximum font size of 24 pixels, we could calculate like so: 24 ÷ (2 ÷ 100) = 1200px. In ems, that would be: 1.5 ÷ (2 ÷ 100) = 75. Then, above 75 ems, we would reset the font size to a fixed value.

@media screen and (min-width: 75em) {
  html {
    font-size: 1.5em;
  }
}

These calculations are not difficult, but I find that a table helps us to visualize the breakpoints2 and the rate at which fonts scale with different viewports units. The viewport unit values are across the top, and the device resolutions run down the left side of the table.

1vw 2vw 3vw 4vw 5vw
400px 4px 8px 12px 16px 20px
500px 5px 10px 15px 20px 25px
600px 6px 12px 18px 24px 30px
700px 7px 14px 21px 28px 35px
800px 8px 16px 24px 32px 40px

Looking at this table, you can see that we have little control over the rate at which the viewport units change. Using viewport units alone, we are limited to the font sizes available in a single column of the table.

Controlling The Rate Of Scale Link

If we wanted to choose a font size of 16 pixels at a screen resolution of 400 pixels and then transition to 24 pixels at a resolution of 800 pixels, we wouldn’t be able to — not without a breakpoint. As well, you might have noticed we have been calculating the breakpoints for the minimum and maximum font sizes, not choosing them.

How do we get around these limitations? The answer is to use calc()3. Using calc() and viewport units together, we can get advanced fluid typography that scales perfectly between specific pixel values within a specific viewport range. We simply need to create a basic mathematical function.

Image of a function: calc(16px + (24 - 16) * (100vw - 400px) / (800 - 400))4
(View large version5)

This function takes a value within a range and works out what the new value would be if applied to a different range. So, if we had the numbers 1 and 100 and a value of 50 and then applied this to a new range between 1 to 200, our new value would be 100. Both of these values remain right in the middle of the range.

This is a common function for mapping values, and I’ve used it a lot when working with data in JavaScript. I was curious about the possibility of using functions with calc(), and when I noticed that this was a purely mathematical function, I knew that all I needed was a variable. That’s the key difference with viewports: The viewport’s size is variable. A value of 100vw is the variable in this equation because the resolved value of 100vw changes as the viewport’s size changes. With this initial idea, I took a while longer to get the function to work. The calc() function handles unit types in equations in very specific ways. If you are interested in this type of thing, I highly recommend reading the W3C’s specification on unit types and values6; if nothing else, it will make for great conversation at your next dinner party.

Though the calculation looks slightly complex, it is fairly simple. We choose the minimum and maximum font size and the screen sizes over which the font should scale and then plug them into the equation. We can use any unit type, including ems, rems or pixels. I’ve been using pixels for the examples in this article because they make it easier to understand the concepts, but I usually use rem units in my work. Whichever you choose, the only thing to remember is that you must use the same unit type for all values in the equation and you must strip the units, as shown in the example.

If you don’t want to write this by hand, plenty of tools make it easier, including mixins for Sass247 and LESS258 and a PostCSS269 plugin. However you roll, you’re covered!

Maintaining Ideal Line Length Link

In his book The Elements of Typographic Style, Robert Bringhurst suggests that a comfortable line length is around 45 to 75 characters.

Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal.

The same rule can be directly applied to fluid typography, and, in many cases, achieving a consistent line length as the text scales is possible.

In a responsive approach, in which we adjust the font size at set breakpoints, we will often also arbitrarily adjust the width of a container to maintain the right line length. However, with fluid typography, adjustment at specific breakpoints becomes unnecessary. Just set the size of the container to scale at the same rate as the font. We can use the calc() technique described above on the width property just as easily as we do on font-size. This makes it easy to maintain a perfect line length — and I have noticed my style sheets are far easier to read and maintain, too.

Be aware that maintaining an ideal line length becomes impractical on very small screens. There comes a point when reducing the font size to maintain an “ideal” reading length will impair readability. We just have to accept this and set the container’s width to something sensible for mobile devices.

Implementing A Modular Scale Link

A modular scale is a series of numbers that are harmoniously proportional to each other. This is best described visually:

Image of the senctence What is modular scale repeated six times but in different sizes10
Each heading is exactly 1.2 times bigger than the preceding heading. (View large version11)

Different scales work better for different screen sizes.

Comparison of a modular scale on a smartphone in portrait and a desktop screen12
(View large version13)

On a small screen, heading sizes should be more uniform; a large screen has room for greater variation. We can use the typographic techniques described above to fluidly transition between different modular scales. Simply pick a ratio for small screens and a different ratio for large screens, and then work out the minimum and maximum font sizes for each heading level.

To calculate the modular scale, take the base font size and multiply it by the desired ratio to get larger numbers. For smaller numbers, divide. Repeat this process with subsequent results to get each required step in the scale.

Larger Link

  • 1em × 1.125em = 1.125em
  • 1.125em × 1.125em = 1.266em
  • 1.266em × 1.125em = 1.424em
  • 1.424em × 1.125em = 1.602em

Smaller Link

  • 1em ÷ 1.125em = 0.889em
  • 0.889em ÷ 1.125em = 0.790em
  • 0.790em ÷ 1.125em = 0.702em
  • 0.702em ÷ 1.125em = 0.624em

Let’s use 1.125 as our minimum scale and do the same calculations for 1.250 as our maximum scale. We’d then apply different steps in the scale to our heading levels.

  • Minimum scale: 1.125
  • Maximum scale: 1.250
Heading level Minimum font size Maximum font size
Heading 1 1.602em 2.441em
Heading 2 1.424em 1.953em
Heading 3 1.266em 1.563em
Heading 4 1.125em 1.250em

I’ve set up an example of fluid modular scale headings on Codepen14 for you to look at. You can read more about the significance of modular scales in Tim Brown’s article “More Meaningful Typography15.”

If you need help choosing an appropriate scale, I recommend the websites Type Scale16 by Jeremy Church and Modular Scale17 by Tim Brown and Scott Kellum.

Maintaining Vertical Rhythm Link

Vertical rhythm has to do with maintaining consistent and proportional space between elements on the page. You can find out more about vertical rhythm in Espen Brunborg’s article “CSS Baseline: The Good, the Bad and the Ugly18.”

To maintain vertical rhythm in our layout, we need to set the vertical spacing of each element as a proportion of our baseline measure. One thing many people find challenging with responsive typography is finding a vertical rhythm that works for both small and large screens. Typically, we might want different baseline measures for small and large screens, or we might want to use different proportions.

With fluid typography, the baseline can be fluid, just like the font size. In fact, if we have already set the root element to a fluid value, we can use em or rem units, and we can use calc() to make this easy.

Let’s say we make 1.5rem our baseline. Let’s set the padding on the body element to a single unit of our baseline.

body {
  padding: 1.5rem;
}

We’ll do the same for the line height and margins.

p {
  line-height: 1.5rem;
  margin-bottom: 1.5rem;
}

For heading elements, I want a different line height. However, I want the height of the line plus the margins to equal an increment of the baseline. This is where calc() helps.

h1 {
  font-size: 2rem;
  line-height: 2rem;
  margin-top: calc((1.5rem - 2rem) + 1.5rem);
  margin-bottom: 1.5rem;

}

In this example, the total height of the heading element plus the margins will be 3rem, which is exactly twice the value of our baseline.

I’ve created an example of this technique19 using Sass variables so that you can play around with different baselines measures to see how it works.

In the future, custom CSS properties will make this technique even more interesting. We will be able to use CSS variables in calc() expressions to change our baseline measure with media queries.

Working With Constraints Link

Perhaps you want to implement fluid typography on a website that has existing layout constraints, or you have to work within a predefined layout in WordPress or Bootstrap. In this situation, the containers would likely not be fluid or, if they are, probably won’t change at the same rate as the font size.

I recently helped to implement fluid typography for the Australian Government’s Department of Human Services. It’s a large website with challenging content, and we had to work with an existing design. I had two main concerns in implementing fluid typography on such a heavily trafficked website.

First, how could I prevent the layout from breaking? In particular, I expected content in navigation containers to overflow when the text size changed at a different rate from the container. To my surprise, this wasn’t a problem.

In fact, it turned out to be quite the opposite. Content now naturally adapted to fit containers, whereas previously it needed adjustment at certain breakpoints. Overall, the style sheet needed fewer media queries, and, for the most part, components needed far fewer style declarations.

This was an unexpected benefit, and in many places we ditched the design treatment for tablets because the desktop presentation now worked on smaller screens.

Below is an example of a navigation component that previously needed several adjustments at different screen sizes. While not perfect at small sizes, it holds together and remains functional, without breaking.

A colorful navigation component adjusting to the viewport-width20
(View large version21)

My second concern was that, because I had to work with some fixed widths, I knew I could not always achieve the ideal length of characters per line. Instead, I adjusted the font size to be within the ideal length on phones and tablets — where I think it matters most.

I had to accept that, because the main container does not scale at the same rate as the text, some text would inevitably reflow when the browser is resized. This was a concern only because I did not want readers to lose their place when changing the device’s orientation. Because we could not avoid this, the only thing we could do was to test the impact on certain devices. With the choices we made, luckily the reflowing was hardly noticeable on mobile devices, and even on large tablets the impact was minimal.

In the end, we were happy with the result. While we could do more to improve the typography, without a doubt we’ve improved the readability of the website. With the lessons learned from implementing fluid typography, the next iteration of the design will likely have a strong focus on typography and readability.

Tips For Implementing Fluid Typography On An Existing Website Link

  • Carefully choose the rate of scale and the minimum and maximum font sizes that work best with your design.
  • Use em units for font sizes. If you need to turn off fluid typography in a particular container, such as the navigation, set the font size of the container to a fixed value. Em values in this container will then be relative to the fixed value.
  • Similarly, if you need to, you can set fluid typography only for certain containers. If you set the font size of a particular container to be a fluid value, then all em values in the container will become fluid.
  • Reflowing text is not necessarily a bad thing if it only happens when the browser is resized or the device’s orientation changes.
  • Maintaining a perfect line length might be impossible. Aim for an ideal line length on mobile and tablet first.

Browser Support And Bugs Link

I often hear that Safari, and mobile Safari in particular, has significant bugs with both viewport units and calc() expressions. However, more often than not, specific problems are not mentioned, so I thought I would do my own testing.

I tested calc() expressions and viewport units on their own, as well as the advanced fluid typography techniques that combine viewport units and calc(). I didn’t find any problems that would stop me from using these techniques today.

I found that both calc() and viewport units work fine in modern browsers. However, in versions of Safari below 8 and in Internet Explorer below version 11, viewport units when used in a calc() expression are not re-evaluated when the browser window is resized.

You can force an expression to be re-evaluated with additional media queries:

  /* Older browsers */
  html { font-size: 16px; }
  
  /* Modern browsers only need this one */
  
  @media screen and (min-width: 25em){
    html { font-size: calc( 16px + (24 - 16) * (100vw - 400px) / (800 - 400) ); }
  }
  
  /* Safari <8 and IE <11 */
  @media screen and (min-width: 25em){
    html { font-size: calc( 16px + (24 - 16) * (100vw - 400px) / (800 - 400) ); }
  }
  @media screen and (min-width: 50em){

html { font-size: calc( 16px + (24 - 16) * (100vw - 400px) / (800 - 400) ); } }

This technique forces Safari below version 8 and Internet Explorer below version 11 to recalculate the font size at set breakpoints.

Forcing old browsers to recalculate the layout with a window resizing event in JavaScript might be possible, but I could not find a reliable method of doing so, and it could impair performance. In most cases, forcing a recalculation at set breakpoints should be an acceptable fallback for these browsers.

For legacy browsers that don’t support viewport units22 or calc() expressions23, the fluid technique will simply be ignored. If sensible defaults are set, this technique can be applied with progressive enhancement.

Using Fluid Typography Today Link

If you plan on implementing fluid typography today, first decide on the approach you are going to take.

If the entire design is going to be fluid, then you will probably want to consider making the root em fluid, by declaring a font size with a fluid unit on the html element. You can then use em and rem units throughout the rest of the design.

Choose your minimum and maximum font size carefully. At this point, you’ll need to decide whether to use viewport units directly or to exert more precise control over the rate of scale. If the latter, then the mixin for Sass247 or LESS258 or the PostCSS269 plugin will make things easier.

Make sure to get the minimum and maximum font size right. This is the most important decision. Once you change the root em, the font size for all other components will be relative to this. Changing this late in a project could mean that you have to adjust everything.

Don’t forget to declare a default font size before implementing a fluid technique. This default will be used in browsers that don’t support fluid units, and it does not need to be the same as your minimum font size.

Finally, consider the constraints of your design and how you are going to approach things like heading levels and line length. Look at the techniques in this article. If you have components other than headings that you want to scale at a different rate from the regular text, consider readability and the maintenance of style sheets carefully before adding many calc() expressions.

I hope you feel encouraged to think about where fluid typography might fit in your next project.

Essential Reading Link

Further Reading Link

(rb, vf, il, al)

Front page image credits: “Fluid Type3728” by Trent Walton

Footnotes Link

  1. 1 https://www.smashingmagazine.com/2015/06/responsive-typography-with-sass-maps/
  2. 2 https://www.smashingmagazine.com/2014/07/breakpoints-and-the-future-websites/
  3. 3 https://www.smashingmagazine.com/2015/12/getting-started-css-calc-techniques/
  4. 4 https://www.smashingmagazine.com/wp-content/uploads/2016/05/advanced-calc-800-opt.png
  5. 5 https://www.smashingmagazine.com/wp-content/uploads/2016/05/advanced-calc-800-opt.png
  6. 6 https://www.w3.org/TR/css3-values/
  7. 7 http://www.sassmeister.com/gist/7f22e44ace49b5124eec
  8. 8 http://codepen.io/MadeByMike/pen/RWJyML
  9. 9 https://www.npmjs.com/package/postcss-responsive-type
  10. 10 https://www.smashingmagazine.com/wp-content/uploads/2016/05/what-is-ms-800-opt.png
  11. 11 https://www.smashingmagazine.com/wp-content/uploads/2016/05/what-is-ms-800-opt.png
  12. 12 https://www.smashingmagazine.com/wp-content/uploads/2016/05/different-scales-800-opt.png
  13. 13 https://www.smashingmagazine.com/wp-content/uploads/2016/05/different-scales-800-opt.png
  14. 14 http://codepen.io/MadeByMike/pen/VvwqvW
  15. 15 http://alistapart.com/article/more-meaningful-typography
  16. 16 http://type-scale.com/
  17. 17 http://www.modularscale.com/
  18. 18 https://www.smashingmagazine.com/2012/12/css-baseline-the-good-the-bad-and-the-ugly/
  19. 19 http://codepen.io/MadeByMike/pen/0dbc9b82769c3e2a0cbfc3192bcaabd3?editors%3D0100
  20. 20 https://www.smashingmagazine.com/wp-content/uploads/2016/05/component-example-full-opt.png
  21. 21 https://www.smashingmagazine.com/wp-content/uploads/2016/05/component-example-full-opt.png
  22. 22 http://caniuse.com/#feat=viewport-units
  23. 23 http://caniuse.com/#feat=calc
  24. 24 http://www.sassmeister.com/gist/7f22e44ace49b5124eec
  25. 25 http://codepen.io/MadeByMike/pen/RWJyML
  26. 26 https://www.npmjs.com/package/postcss-responsive-type
  27. 27 http://trentwalton.com/2011/05/10/fit-to-scale/
  28. 28 http://trentwalton.com/2012/06/19/fluid-type/
  29. 29 https://css-tricks.com/viewport-sized-typography/
  30. 30 https://www.smashingmagazine.com/2015/06/responsive-typography-with-sass-maps/
  31. 31 https://www.smashingmagazine.com/2015/05/benton-modern-typography-case-study/
  32. 32 http://www.elliotjaystocks.com/blog/responsive-web-typography/
  33. 33 http://www.zell-weekeat.com/responsive-typography/
  34. 34 http://blog.bugsnag.com/responsive-typography-with-rems
  35. 35 http://academy.bindtuning.com/fluid-type-for-responsive-websites/
  36. 36 https://responsivedesign.is/design/responsive-typography
  37. 37 http://trentwalton.com/2012/06/19/fluid-type/

↑ Back to top Tweet itShare on Facebook

Mike is an independent web developer from Australia who has worked on some of Australia's largest websites as well as some of the smallest community sites. When he's not building sites or blogging, he likes to experiment with code. He loves learning new things and finding techniques that challenge what we think is best practice. And when he's not exploring the digital landscape, he likes to explore the world. Currently trying to find a way to do both those things at the same time.

  1. 1

    Very nice technique. I already knew about it from your previous articles(Precise control over responsive typography), but this one is much more in depth.

    Now, if someone would package all of this in one neat Sass library, fluid type, choice of modular scales and maintaing vertical rhythm !

    Unfortunately, my Sass sucks big time, so that counts me out :)

    13
  2. 2

    Felipe Fialho

    May 10, 2016 1:20 pm

    Thanks for the article!

    I use the Rucksack to help me to build my responsive typography and this is the better article about it.

    2
  3. 3

    This is a great, comprehensive look at a topic I’ve been trying to understand recently! Just wanted to say thank you for the great explanation.

    9
    • 4

      Michael Riethmuller

      May 10, 2016 7:25 pm

      It’s a pleasure. I’m very glad to be able to expand on the original blog post now that I’ve had more feedback and experience using these techniques in the wild.

      3
  4. 5

    Scott Rothman

    May 10, 2016 7:09 pm

    VW and VH are honestly probably the greatest additions to CSS3. Finally easily proportionally scaling text

    4
  5. 6

    Wow! This is an awesome article especially because you talk about modular scale as well as vertical rhythm. Fluid typography is a “feature” that has often been requested by our graphic designers but my frontend colleagues and me didn’t have the possibility to make it work. I think your article can lead us the way.

    But generally I would put this issue in question. Is a larger font for a larger screen really needed? In my opinion font-size should depend on the distance from the user to the screen. A user of a larger screen doesn´t automatically have a bigger distance to his screen. The 16px browser default is a really good font-size for small as for large screens, too.

    I think we should more consider on trying to use the extra space we have on larger screens with meaningful content instead of just upscaling the font. If you compare a website to a native desktop app e.g. Photoshop, then Adobe didn’t make the fonts bigger in Photoshop UI. They give the user the option to rearrange or maximise all panels. You can show all panels if you have enough space for.

    I think this is an example of how we could use the space in our GUIs or even websites as well. Maybe we could think of always showing the second level of our menu or placing comments of our Blog on the right side instead of under the article. There are tons of opportunities but just scaling up the font seems like a fault for me. It´s time to rethink websites more as a horizontal then as a vertical concept.

    15
    • 7

      Here’s an example of how fluid type can be used to scale the whole UI in a web app, essentially making more space available on smaller screens: http://xrespond.com

      6
  6. 8

    luminarious

    May 11, 2016 3:36 pm

    I was thinking along similar lines last year and ended up with logarithmic scaling done in Javascript: http://codepen.io/luminarious/full/VLdBrd/

    The reasoning behind this approach was that scaling up infinitely makes little sense, so for most use cases it’s better to taper off the increase in font size and switch layout.

    2
  7. 9

    And somehow I’m missing the note about the issues with that in almost any browser. So if you want to use it, you should rely on one of the few bugfills that are around for this feature:

    a) Viewport Units Buggyfill™
    b) vminpoly (its actually a polyfill, but it also fixes issues with otherwise “supporting” browsers)

    I’ve used the first one lately within a project of mine, and it indeed helped a lot (still is helping, actually) ;)

    cu, w0lf.

    ps: these are also the same recommendations as found at CanIUse.com. Nothing new here, kinda.

    4
  8. 10

    I think more practical examples on line length and modular scale would be good. overall nice tutorial though.

    1
    • 11

      Mike Riethmuller

      May 13, 2016 9:22 am

      Thanks Raj, how could I make the examples more practical? I’d be more than happy to update the demos or make new examples if it would help.

      2
      • 12

        Hi Mike,

        just give us some sample code which would be easier for newbies like me to follow and eventually go on to customize it the way we want. I think a some sample code, more related to the real world would be good.

        Thanks. :)

        5
  9. 13

    DAVID VASQUEZ

    May 13, 2016 7:51 pm

    Michael, great article! I found it very informative.

    One thing I did notice, however is that when attempting to scale up the font size manually via the browser (for example cmd +) the fonts remain the same size and only margins/padding appear to increase. This effectively takes away the user’s ability to scale up the font size manually which can be a real problem for those with poor eyesight.

    Is there any way to prevent this accessibility handicap outside of coding your own font resize control on the website itself?

    2
    • 14

      Michael Riethmuller

      May 14, 2016 8:46 am

      Hi David, just use em or rem units in the calc() expressions. If you don’t set a fixed value on the root em the text will scale with use preferences.

      -2
  10. 15

    Angelia Baladon

    May 14, 2016 3:12 am

    I’m having a difficult time wrapping my head around a calculation that will achieve this … “Just set the size of the container to scale at the same rate as the font” … can you possibly elaborate a bit on how to make that happen?

    0
    • 16

      Michael Riethmuller

      May 14, 2016 9:00 am

      Hi Angelia, sure I’ll try. If you’ve changed your base font-size (root em) like this:

      html { font-size: calc(12px+2vw); }
      

      Since we’ve changed the root em all we need to do is make sure the width of our container is set with rem units and it will scale at the same rate.

      body { width: 60rem; }
      

      This works with more complex examples also. Such as the fluid vertical rhythm example in the article:

      http://codepen.io/MadeByMike/pen/0dbc9b82769c3e2a0cbfc3192bcaabd3

      Hope that helps!

      0
  11. 17

    Overall a nice article. Thank you. Especially the min and max calculation, wich bothered me a long time.

    But, one may not want to set the line-height to 2rem for the headlines.
    Instead I would prefer a multiple of the base line-height (1.5rem). Because right now, the line-height of the headlines is breaking the vertical rhythm when exceed one line.

    Regards.
    Manuel

    1
    • 18

      I could not make the examples work: Spanish do have much longer titles and the entire thing broke upon trying to get the vertical rhythm and the proportional scales to work together.

      I still thinks it is a great idea, just don’t know how to achieve it correctly.

      The Great Discontent seem to manage great results on the matter

      0
  12. 19

    Mike: thanks for the great article, it is what I was looking for regarding the subject. This can be combined with golden section proportions to get interesting results with white space.

    I have a question: I’m trying to convert the SASS mixin to a Stylus mixin but found many problems that appear to be related to sintaxis. Do you know of anyone that can help me out with the conversion? It is very close to be useful as it is.

    0
  13. 20

    I love the idea of fluid typography. Thank you for your article.

    1
  14. 21

    Ok, so here is my Sassy implementation.

    The Gist – https://gist.github.com/jonburger/21a5e798d86b3b8e24d6686167be47b3#file-fluid-typography-css

    Basically it’s fairly robust:

    1. without support for anything, the font size will be the minimum font-size (14px) so nothing will break.
    2. with support for mediaqueries and not vw or calc or both then the font will jump up a pixel size at every appropriate breakpoint (I’m using http://include-media.com for syntactic-sugar, but you could rewrite without this)
    3. with support for mediaqueries and calc and vw it will work as the article describes, with the fixes for older Safari and IE too

    Ain’t it pretty!? Haha – works well tho :)


    $base_font-size-min:14px;
    $base_font-size-min-at-width:320px;

    $base_font-size-max:18px;
    $base_font-size-max-at-width:2560px;

    html {
    line-height:1.5; // 24px at font-size 16px

    font-size:$base_font-size-min;

    $steps: strip-units($base_font-size-max - $base_font-size-min);
    $increment: ($base_font-size-max-at-width - $base_font-size-min-at-width) / $steps;
    @for $i from 0 through ($steps - 1) {
    $base_font-size-at-breakpoint: $base_font-size-min-at-width + $i * $increment;
    @include media(">#{$base_font-size-at-breakpoint}") {
    font-size:$base_font-size-min + ($base_font-size-max - $base_font-size-min) * ($base_font-size-at-breakpoint - $base_font-size-min-at-width) / ($base_font-size-max-at-width - $base_font-size-min-at-width);
    font-size:calc(#{$base_font-size-min} + #{strip-units($base_font-size-max - $base_font-size-min)} * (100vw - #{$base_font-size-min-at-width}) / #{strip-units($base_font-size-max-at-width - $base_font-size-min-at-width)});
    }
    }

    @include media(">#{$base_font-size-max-at-width}") {
    font-size:$base_font-size-max;
    }
    }

    1
    • 22

      I managed to get the basic implementation of Michael’s script on Stylus, but trying to mix the vertical rhythm mixing with the modular scale example proved impossible. Did you managed to do that? I don’t see any code to preserve vertical rhythm in your example.
      I’ll read more on the subject on the articles referenced to see if I get to implement something that works

      0
  15. 23

    Hemang Rindani

    May 24, 2016 1:00 pm

    Responsive sites or in the context of this article, web applications that work well on any device is a need of any organization. We have witnessed that responsive designs are a trend in market and has easily replaced adaptive designs. With even enterprise web content management services like WordPress, Sitefinity CMS, etc providing built-in features of making the application responsive, it has been lot easier for developers to deliver sites that run well on desktops as well as hand-held devices.
    Yes with responsive design, it is required to go through the check points and according to article, I see fluid design will help us tackle that issue with view points. Will implement this and get back here.

    1
  16. 24

    Hi Mike. Thanks for awesome writings.
    One question:
    How do you maintain vertical rhythm while having two modular scale ratios? In the article, you mentioned setting up root font-size and make line height and margins relative to that. (like your codepen example(http://codepen.io/MadeByMike/pen/0dbc9b82769c3e2a0cbfc3192bcaabd3) But I am trying to keep the same root font size and have two different scale ratios that would maintain the vertical rhythm in em. Any ideas?

    0
  17. 25

    Because when I do something like this:


    /* calc(baseline / ( constantly calculated font )) */
    calc(1.7 / (1.601806640625 * 1em + 1.555527877696 * ((100vw - 34em) / 33 )) * 1)

    The browser won’t read the syntax. (or at least in Chrome) Because it’s deeply nested? I can’t think of any workaround.

    0
    • 26

      Mike Riethmuller

      June 1, 2016 3:14 pm

      Thanks Ernie,

      Good questions! I’ll answer the easy one first. :P The reason the example provided doesn’t work is the left side of the calc() equation is a whole number and the right side resolves to a unit. This is like trying to say calc(16 / 2em) it’s not going to work.

      As for combining fluid vertical rhythm and fluid modular scale heading this is not something I’ve done yet. If possible the cost of complexity of the calc equation might not be worth the gain. It’s an interesting question and sorry I don’t have the complete answer. Although I’m excited to see if CSS variables help make this possible\easier.

      0
  18. 27

    Simon Stratford

    May 30, 2016 9:55 am

    I need to jump on this, thanks for the info.

    2
  19. 28

    Mike,

    This article will help us to reduce code for @media quires and save time and keep the page smooth.

    Thanks Again

    2
  20. 29

    Great article!

    I wanted to point out something about the “Maintaining Vertical Rhythm” section. In your example, you are using CSS calc() to calculate the margin-top to use. But, since you are only using rem units and there is no dynamic variable involved here you can just calculate those in SASS instead of forcing the browser to calculate it.

    Here is a forked version of your example to show the change: http://codepen.io/infernocloud/pen/PzgQEP

    //These produce the same value unless one of the variables is a viewport variable.
    margin-top: calc((#{$baseline} - #{$h1}) + #{$baseline});
    margin-top: ($baseline - $h1) + $baseline;
    
    0
  21. 30

    Pedro Ferrari

    August 20, 2016 4:24 am

    This is remarkable, thank you for sharing.

    1
  22. 31

    I prefer to write short – set the base scale of the :root element. Then override percentage – http://codepen.io/dimaZubkov/pen/JKpEaJ (http://www.responsinator.com/?url=http%3A%2F%2Fs.codepen.io%2FdimaZubkov%2Fdebug%2FJKpEaJ)

    0
  23. 32

    Már Örlygsson

    September 2, 2016 2:21 pm

    Michael, BTW this unwieldy font-size calc() rule


    font-size: calc( 16px + (24 - 16) * (100vw - 400px) / (800 - 400) );

    …can be mathematically simplified down to this:


    font-size: calc(2vw + 8px);

    Here’s an example of a simple Stylus function that performs the simplification automatically: http://codepen.io/maranomynet/pen/ozNpXV

    1

↑ Back to top