XI to Eye - VWSince the launch of the first responsive website we have had fluid grids and images, but our typography has been static. That is, until recently. The rise of support from the browser vendors for viewport units of measurement has changed that and we can now build sites where the type adjusts to the size of the screen. With a little bit of planning and a dash of sass, we can control our fluid type through all of our breakpoints and ensure a proper text line length across all variants of our design. In this edition of XI to Eye I'll give you an introduction to vw units and how we're using them.

Transcript: Fluid Typography with VW Units: XI to Eye

Mike Gibson:

[Slide 1 - 0:00] Hey, it's another edition of XI to Eye. I'm Mike Gibson. I am a designer here at Table XI. You can find me on Twitter @lovehasnologic, and as always you can find Table XI on Twitter @tablexi.

[Slide 2 - 0:15] Today we're going to be talking about something that I've been using quite a bit lately, and it is the VW.

[Slide 3 - 0:22] No, I've not been driving all over the city. VW is part of the view port measurement available in CSS. This is VW, VH, VMIN, whole bunch of cool stuff that lets you size things based on the size of the view port. I'm going to talk about how, specifically, we're using VW's to control the size of our type to create fluid type in the same way that we create fluid images in our responsive designs.

[Slide 4 - 0:53] So what is a VW? If we look at this right here, we have 100 bars going across the screen. 100 VW is always equal to the width of the window. If you want 100 percent, 100 VW is the same thing. The cool thing about it if you're using it, box model properties, such as the width of an item, it does not get affected by things like padding or margin, so it's a true 100 percent, which is always really nice. What this means if 100 VW is equal to the width of the window...

[Slide 5 - 1:33] ...then one VW is one percent of the window width. This green bar that you see here on the screen is one VW. As we start to think about that, we realize that we can use this to control the type in our document.

[Slide 6 - 1:52] What does this actually mean? If we're looking at it, depending on what the size of our browser is, one VW is going to be a different measurement on the screen. At 1,000 pixels wide, one VW is going to be 10 pixels. At 750 pixels wide, one VW is going to be 7.5 pixels. As you can see, that continues no matter what VW unit we throw it in. 3.2 VWs is going to be different sizes on a 1,000 pixel screen, except a 250‑pixel screen. It's pretty cool, but it's not really how we think about type as designers. We're not sitting here doing our designs thinking about type in relation to the page itself, or in relation to other boxed elements on the page. We typically will think of type in relation to other type, so this headline should be X percent bigger than the body copy, so on and so forth. That is where being able to use viewport wiz in smarter ways, but knowing how to target them comes in extremely handy. We actually are in a good situation because we're using SaaS on all of our projects, and we can do that if we remember we have three parts. We have the browser width, we have the end result—the target size of the type—and then we have the VW unit, which makes that relationship between the two.

[Slide 7 - 3:17] What we do is we use this custom SaaS function that we wrote. We have a SaaS function that we call VW. We pass at two of those three known values. We pass at the target size— what size we want it to be—and we pass at our break point, we pass at the point at which we want it to be approximately this size, and then be fluid based on that target. What the function does, it takes those two values, and gives us the third value, the unknown in the equation. We don't know if it's 3.2 VW, or 3.19857 VW, or 3.05943 VW. Those are all really crazy, silly numbers that we don't want to be worrying about. What we do want to be worrying about is the things we know, and what the computer is giving us the rest.

[Slide 8 - 4:08] You can see it here in use. I'm just writing some CSS here for an H1 element. We're saying, "OK, we're building a mobile first site, so it's small sizes. Let's go to a target of 16 pixels," and it will be fluid within that range until it hits this first break point where we reset that target to be approximately 24 pixels instead of approximately 16 pixels. Then it will continue to be fluid until it hits another break point and gets calculated again.

[Slide 9 - 4:39] I can show you the math right here as well a little bit. You can see that the numbers we give it just get slotted into our function, and we get values in return. As you can see, at the smaller sizes, it's 3.2 VW, so it's a bigger number than at the larger sizes. But because a VW is a relative size, the actual type is going to be much larger at that larger size. We're going to look at an example here in a second. Remembering all these numbers, remembering where these break points occur, sometimes it's not fun. You don't want to keep track of all this within an entire project.

[Slide 10 - 5:21] We can actually make this a little bit easier by just using variables for our break points, so we just name our break points one, two, three, so on and so forth. Then we have the exact same CSS, but now we can set our target sizes based on which break point we're hitting, break point one, break point two, break point three. We don't have to remember exactly what those values are. Makes working with this stuff extremely easy as we apply this to an entire design system.

[Slide 11 - 5:48] If we look at this example here, you'll see the type grows and shrinks as the browser grows and shrinks. The relative line length is always going to stay the same throughout because we're sizing the type relative to the view port width. You can see I also have one break point in here that I'm using to resize to apply a new VW unit to the type as we go through as well. Throughout the entire design, we have 100 percent fluid type that we can control as finely as we want to just by adding additional media queries, and using our SaaS function to add a new VW, so pretty cool here.

[Slide 12 - 6:32] If we're looking here at our browser support for VW units, we only got really three areas where we need to be concerned. First off is Internet Explorer. Surprisingly, IE9 and up support VW units. If you're supporting IE8 you need to supply a pixel value as a fall back, and then you can supply your VW sizing. IE8's going to ignore the VW and stick with the pixels. The other major concern here, browser‑wise, is going to be supporting the Android browser. 4.4 and up are the only Android browsers that support the VW unit. This is obviously the stock Android browser that I'm speaking of. Once again, same thing that we're doing with IE8, if you're supplying the pixel value first in your stack, and then supplying your VW unit afterwards, it's going to pick up the pixel, ignore the VW, and you're good to go.

[Slide 13 - 7:30] The only real messy issue is with web kit browsers. Web kit browsers only calculate the VW size on page load, or when an element is repainted. It doesn't recalculate the size on page resize, which is why I was using Firefox in that last example there. You can get around this by using some JavaScript and causing a repaint to occur on elements that have fluid type size like this, and then target that just to web kit browsers, so that it's not running on every single browser. I'll typically use this by just using CSS and adding a zoom one to my elements that have a fluid type size. The performance impact is extremely negligible in that I can't notice it, or see it in any automated testing, or just visually not there, and we get fully fluid type in web kit browsers as well. You can find out more about the browser support by looking up view port units on caniuse.com.

[Slide 14 - 8:37] That's just about it. That's how we're using view port units to make our typography on our websites just as fluid as our layouts and our imagery that goes along with it. It's pretty cool. We've used it on a couple sites now, and have had no problems at all. Just with a couple little extra lines there in your CSS, and a little bit of JavaScript you can support all of the browsers that you may be supporting nowadays. It's pretty cool. Be sure to check back here on the website regularly. We're going to have more XI to Eye's, and until next time. Thanks for checking us out. I'm Mike Gibson, and we're here at Table XI. Find us online at tablexi.com, or on Twitter @tablexi.

Transcription by CastingWords

Want to start visualizing your project risks?  Download our free Software Risk Management template