Responsive Web Typography v2

Flash of Unstyled Text

Responsive Web Typography v2

Check out a free preview of the full Responsive Web Typography v2 course

The "Flash of Unstyled Text" Lesson is part of the full, Responsive Web Typography v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jason reviews the Flash of Unstyled Text (FOUT) effect and how to mitigate the impact on users.


Transcript from the "Flash of Unstyled Text" Lesson

>> Jason Pamental: Again, bring coming back to implementing type. Fout or flash of unstyled text, my favorite way of describing it is this is a feature. It's not a bug. What we want to do, again, is make sure that the content shows up there on the left, as opposed to what happens on the right.

A little bit of history here, when web fonts were first implemented, they would always show the fall back and then flip over to showing the web font once it loaded. Safari very quickly changed and decided they wouldn't show anything until the web font loaded. And when I mean they wouldn't show anything, there was no time out.

So if that web font never loaded, you never got any content. That was really frustrating, there are very few ways around that, other than things like we're gonna look at today. More recently font display has been adopted by most browsers so that in the @font-face declaration you can say font display swap if you like.

Which means as soon as it sees this, it will say okay, I will go to the fall back font, render stuff and then swap it out when the web font loads. That in my mind, is the most desired behavior. That's what I usually lean towards so that we get the content on screen.

And then once the web font loads, it kind of comes into the look that we would expect. But you'll notice that that blocking request with the CSS waiting for the web fonts was even blocking this photo from loading. So, there's a whole lot of other unintended consequences that you end up with by not managing that process.

And it's been possible since 2010, through various different font loading libraries. So, the whole key are these classes. WF for web font inactive or active. And those are not native to the browser, they just happens to be what enough people started to use that it's relatively common. So, I kinda try and standardize on that.

But that's what Typekit will inject in your page, that's what will now inject in your page. So that way if you are using something from a service or you are working on stuff on your own, it sort of stays consistent. And that way, you will always have a class on the html element that you can look at and scope your CSS to style things when they get to the screen.

So, now we can do something really simple like if Trade Gothic is the web font that I want, if I then include right below it, WF inactive body. And I just specify Helvetica and Arial instead of Trade Gothic. Whenever that class is present, it renders the content on screen instantly.

And what we can also do if we like is add styling to that inactive class description, so that we can play around with letter spacing, line height, font size, margins. So that we can minimize the re-flow, and I have a good example that we'll look at today of seeing this action.

It takes a little bit of extra work, because now you're tweaking styles across break points with these non-web fonts. But the benefit that you get out of that is a nearly seamless experience where none of the content moves around. So, when things load up initially and the web fonts haven't shown up yet, the design integrity is still maintained.

As long as you have a fall back font that is even relatively close, you can get it to not reflow. Obviously if you're using like a script typeface or something handwritten, it's a little bit harder, but I will come back to looking at this. Watch that square on the left with the heading back to some conference.

It comes into that hand written font but it still doesn't really reflow or move the design around that much. So it is possible to just get the metrics close enough, so you can imagine it like a jpeg coming in that's all rough and blurry. And then it gets more and more clear.

It's a similar experience. And in a lot of testing with users that I've done, sometimes they just don't even notice. They just tune it out. As long as things stay in the same place and they can interact with the content, they don't even really notice that it went from one font to another one.

I'm not sure what that says about the font choices, but we'll leave that one alone. So I'm stressing this last point because it really has been possible, since less than a year after Typekit launched, for us to manage this process, and it's still not a commonly done thing today.

And that's really disappointing. It clearly means that I'm not popular enough on the web, and nobody is listening to me enough to make this part of their normal workflow. Make me feel better about myself. Build this into your process. I'm giving you a starting point. It's going to make your site and your application so much better for users.

Especially when we're dealing with everything about online and offline, network latency. All of things things are impacted and made better when you have these kinds of fall back tuning in place so that people get a good experience right away. So here's a little bit more of this in action.

So you can see, I'm gonna start over again.
>> Jason Pamental: This is it, what it should look like with the web fonts loaded.
>> Jason Pamental: Now this is, the web fonts have not loaded, but they're not corrected. And what you'll note is, look at the spacing of A Whale of a Tale, that main heading, and Moby's Trip up top, and sort of the line breaks down here in the body copy.

Now, we've added a little bit of correction to it. Things kinda tightened up a little bit and then finally the web fonts load. Nothing's moved around. So, all of the content is stayed in the same place, the navigation hasn't broken or wrapped in a weird way. Things aren't jumping around.

Because of small corrections that only have to get done once, and really, the truth is, you only have to worry about whatever's gonna be in view. So make sure the navigation is okay, the main level headings, and the paragraph size and wrap is close enough. Because really things are gonna load before people start to scroll.

You're really just worried about how does that first screen full of content look. So you don't have to get really deeply into it, you've got to customize three or four different elements to make sure that that loading process is gonna give us smooth experience.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now