Web Font Tips & Tricks

[00:00:00]
>> Jason Pamental: I wanna talk about centered text. Or rather, I wanna talk about how inappropriate and hard to read large blocks of centered text tend to be. And the reason for that is your eye has to travel back to some point to start reading the next line. And if your eye doesn't know where that point's going to be, it's going to slow you down.

[00:00:23]
That is why a smooth left edge, if you are reading English, or a smooth right edge if you are reading something right to left like in Arabic. That makes all the difference in the world to the ease with which you can take in content. So anything more than about two lines of text, if you are centering that text, you are slowing people down.

[00:00:43]
You are making it harder for them to get the point. A lot of people do this, it's built in to a ton of frameworks. Because especially with a responsive site it's easy, because centered text centers easily under this picture and it makes a nice card layout. And It doesn't matter if it's one, two or five across, it's a real problem for people to read.

[00:01:04]
So what I suggest to people instead, and we can look at an example of this later and play around with it, but align the text to the left and simply pad it in one or two m. If you want to have that text visually centered underneath something and not flowing all the way out.

[00:01:22]
You can still left align it, but just pad in that left side and the ragged right side will take care of itself. It will still look visually centered in that card layout, but it won't be hard to read. And the point that I have here goes along with that is the maximum line length.

[00:01:41]
That's another thing you see in responsive sites a lot, is no limit to the width of the text. So as the screen gets bigger and bigger and bigger, you might have 80, 90, 100, or 150 characters on a line, your eye can't follow that. It's just not gonna be a good experience.

[00:01:59]
One of the sort of brain hurst rules is around 65 to 75 characters per line, that's what we're used to. Online, I think people are getting used to reading slightly longer line lengths. So 38em translates to usually around 65 to 70 characters. Now the reason I know that is because I've used a calculator a lot.

[00:02:29]
But by specifying an ems that's tied to the types of size that you're measuring. So it's always relative to the type size that it's applying to. So if that is rendering at 100% or 16 pixels, or 20 pixels or whatever, it doesn't really matter. Because that 38em is relative to the font size of the paragraph itself, you will always have a consistent line length that will be easy for people to read.

[00:03:01]
And you can do an experiment 38, 40, 42em it's all gonna be in the right ballpark, so you can match that with your design. You don't want to end up with really weird gaps, but you still want people to read the text. You want people to be able to read the content.

[00:03:16]
That's the whole goal. So that's why you wanna make sure that you don't let those paragraphs run all the way across the screen. [COUGH] There are some other interesting CSS units out there in terms of sizing things. CH and CX are ones that are supposed to be related to character height or character width.

[00:03:38]
They're not terribly reliable, and I don't think they bring a greater value than simply getting used to what is an translation and just relying on that. That I've found to apply much more universally than saying 75ch, which is supposed to equate to about 75 characters per line. I've not found that to be typically very useful.

[00:04:04]
vw and vh, or viewport width and viewport height, those are tremendously useful. We're gonna be leaning into viewport width units quite a bit today. And those tend to be, well a viewport width unit, there are 100 view port units, either high or wide. It's like percentage, except it works.

[00:04:23]
So view port width units is an interesting way to size types so the type is always proportional to the size of the window. The problem that you can run into there is that window can sometimes get narrower than you expect or wider than you expect and there's no low or high end.

[00:04:39]
We have a solution for that that we're gonna play with. But just know that setting something just in straight view port units does have risks based on the size of the screen being much larger or smaller than you anticipate.
>> Jason Pamental: Font sizing, four years ago, I was still on the fence about using REMs, or sort of Root M's.

[00:05:10]
They're fine, there are reasons to use an M or a REM. I'm gonna talk about the differences just a little bit. It has started to become acceptable or fashionable again to go back to using pixels. Don't do it, it's a bad idea for a couple of reasons. When you set something in pixels right now, it's using something, it's technically a reference pixel not an actual one.

[00:05:36]
So your device, like an iPhone 10, reports something like 380 pixels across for the whole screen when in truth the real resolution is about three times that. Every device is doing something slightly different to report back what that reference pixel value is. And every once in a while you find devices that actually just go with true resolution when you don't expect it to.

[00:06:03]
If you're setting things in pixels, you might find your content the size of a postage stamp in the middle of a touch screen laptop. If you had set it in EMs, you wouldn't have this problem. So break points, it's really easy. When you're setting break points in EMs, it's always going to be relating back to 16 pixels, it just always works that way.

[00:06:24]
So 1em, 16 pixels, if you wanna breakpoint that is somewhere around 400 pixels, just divide by 16. You don't have to put any more thought into that. Whatever the pixel value is that you were going to use in your breakpoint, divide by 16, use an. Don't use a REM, use an.

[00:06:44]
REMs are great when you want to always come back to something like setting a consistent max-width for headings and body copy, we'll be doing that later today. REMs are little bit different than in And that REM is always going back to the root value which is typically going to be something like 16 pixels.

[00:07:05]
Unless you set the body or the HTML element to be some other size and everything references back to that point. EMs are always relative to whatever the parent is somewhere along the way. So if you've set a font size on a div and then you set a font size on an H1, it's referring back to the containing div, not the root.

[00:07:27]
So that's where people get into trouble with EMs. But sometimes you really need it relative to the thing itself. So sizing margin on a button in EMs is relative to the text size that's on the button, that makes sense. You want that actually to flex and grow with the size of the text not necessarily with the size of the root.

[00:07:49]
So there's a lot more to it than that. It's just when you set all of these things in a relative unit, that means if somebody needs to resize the text, if they need an accessibility setting, all of these things scale uniformly. If your break points and margins and text sizes are all set in EMs or REMs, everything scales smoothly together.

[00:08:14]
It's a far better solution for accessibility, and it also means that your design will work with that page zoom flawlessly. It also means that when that reference pixel standard changes, your design will still work. Because this is all going back to whatever is deemed by the browser or device manufacturer to be a readable size of text, whatever that 100% value is.

[00:08:37]
So it's not that hard if you need to write a mix in or something so that it outputs EMs or REMs when you put in a pixel value. That's totally fine as we use these tools so we don't have to think that hard about some of these things.

[00:08:51]
But just know that in the output value, what gets shipped to the browser, the only place where pixels belong is in maybe a border thickness. Other than that, there's no need to have a pixel value in your CSS. That may be something of a controversial statement to some people, but I will stand by that and I have since the beginning of responsive design.

[00:09:13]
And I never get into trouble with this stuff. And I've seen many other designs fall apart when one little thing changes. If we keep it all relative, it's all based around readable text, that is the point. All of our projects, all of our websites, all of our apps, the core of it is the text on the screen in order to get that point across.

[00:09:34]
So someone can buy a thing, can read a thing, can go do a thing, they're reading something. Instagram is pretty much the only place where that's not really going to be that important, except reading the comments is hilarious. So, still, text.
>> Jason Pamental: This last part is always a struggle.

[00:09:59]
But if you never put Lorem Ipsum into your design, you will never fall victim to not knowing how it will really behave. Because when you put the exact same string of text in every single card content of the design while you're proofing it, you're never gonna know what's gonna happen when a real headline goes in and you find that weird little in between space.

[00:10:23]
You'll never know it's there if you're not using real content. So it doesn't matter if it's current. Go take some stuff from Moby Dick, that's my go to. I always go back and use that in my sample designs. Or just go copy the existing content. But make sure that you use real stuff.

[00:10:41]
So that way when you're working on your card layouts, when you're working on the article design, the basic page framework navigation whatever it is, if you've got real words you've got real design considerations. If you don't do that and it's just link one, link two, link three when you're trying to lay out your navigation, you have no idea what's gonna happen when you have a 37 word link that goes in there.

[00:11:05]
Because I guarantee you it's gonna happen, because as soon as we put the admin user in control of the content management system, they're going to do six things that you never knew were even possible in the first day. And that's just the nature of things. But that's what we have to learn to work with as designers and developers, to build a resilient web.