Manage your website’s legibility using text-rendering and its alternatives

Hiya! How are you doing? Today’s article is a brief overview of a topic I recently discovered. In fact, the idea came to me a couple of weeks ago while I was reading a library style code and found out something I hadn’t seen before. So I thought it was great to investigate and share it with you all. We’re talking about a CSS property –which is not really from CSS– that allows us to have control over our texts legibility, the text-rendering. From this discovery, I got to other properties that allow us to manage fonts at a similar level.

So… let’s check it out!

Intro: the idea of legibility in the web era

When we mention the word “legibility” we are referring to a set of features that make typography, and therefore text blocks, easy to read for the human eye. There are plenty of elements that can affect legibility, not only regarding the typography anatomy itself, but also the layout, sizes, spacing… not to mention the matter of colours and contrast. We’ll check in detail some of these variables another day. The main point now is to remember that legibility is of paramount importance in UX, and in a good design.

Moreover, web and mobile formats have their own challenges. It will never be as comfy for the eyes to read over a light-based screen instead of paper. We also won’t keep the same distance from a book that we keep from a screen.

Let’s face it, reading on a screen makes our eyes sore. We may have gotten used to it and it’s obvious it has plenty of advantages, but we still need to take care of the soreness it produces. So, part of a designer’s responsibility is to apply all possible measures for a better, more efficient and quicker reading process for our users.

One of those measures is, precisely, a variable that controls the kind of rendering browsers use for all font families, known as text-rendering.

Text-rendering: CSS, but no.

Text-rendering is officially a CSS property, supported by most of the browsers (except for the terrible IExplorer), and it is nothing new, precisely. Still, it is not defined in ay CSS standard. What? What’s the deal? The trick is that text-rendering is not from the CSS domain but is a SVGpropriety, the vector image XML language.

The thing is that when we call this property from CSS, we are telling the compatible browsers -those based on the Gecko engine (like Firefox) or the WebKit engine (Chrome, Safari, Opera, etc.)- how they must render the text inside their HTML and XML. And that is because mainly most the fonts we use today are based on vectors and not bitmaps.

In other words, we can give precise instructions globally to browsers, which are the ones processing the information they receive from the font families tracing, for the treatment of Open Type fonts. With this degree of freedom, we can choose to show the font types in a more legible way, affecting the kerning(spacing among certain letters) or ligatures(tracing between letters), or we can make performance a priority and optimize the loading charge getting rid of any additional computing charge.

Note: kerningis a typography concept that refers to the existence of particular spacing according to the combinations of certain characters, like the T and the e, for instance. It shouldn’t be mistaken with the tracking, or letter-spacing in CSS, that increases or reduces the spacing between letters in a regular way.

And what choice can we make? Let’s see our options.

Text-rendering values

Auto

text-rendering: auto;

This is the default value, what is usually what we have. With it, it’s the browser who chooses when it should make the speed a priority or the legibility when rendering the text blocks. Obviously, this is also something each browser will on on its own terms, so if we leave it in auto we may get different results depending on what we are using.

In general, the criteria browsers use to choose the kind of rendering is the text-size. So, as a standard, auto improves legibility while the text size is 20px or less, while it improves speed for any font that renders in a bigger size. Still, this is again something that each browser may manage differently so keep it in mind. While in most of the cases this will have a good result, we have text-rendering if we desire to have a more controlled approach.

Optimize Speed

text-rendering: optimizeSpeed;

This option allows us to give more importance to speed, above visual accuracy and legibility. If we choose this value the browser will disable all kerningoptions, as well as the ligatures, and show directly all characters one after the other without computing anything or reading any particular info provided by the font type.

Optimizing the speed can be paramount in cases where there is a lot of text or very big text used. Also, maybe it’s your only option for certain Android and iOS versions, as according to the device processing capacity you may get bad results.

Optimize Legibility

text-rendering: optimizeLegibility;

This is the opposite situation: we prioritize legibility. By doing so we are giving permission to the browser to take all the time an resources it requires to calculate how it should show certain fonts in their best way, depending on each pair on characters and any other information provided in the font file. Here, the browser won’t take in account the size of the text or how much text it has to render.

Using this we will have a happy reader, as visually we have improved the experience, but it comes with downsides. We’ll be sacrificing performance, therefore we’ll affect theloading times (so it is bad for SEO) and we may get imporant undesired behaviours in mobile devices.

In fact, we should be careful when using optimizeLegibility in cases where we have more than 1000 words in our page, as mobile browsers can go very slow or even freeze (specially in Android ones). So, if you want to have good legibility, be sure to use media queries in CSS to protect the user experience in smaller devices.

Geometric Precision

text-rendering: geometricPrecision;

The last option forgets legibility and focuses on a different matter: the accuracy of the text scaling and their spaces. It strives for exactitude. As you probably know, usually type fonts don’t scale in a linear way. If we have a 16px body size for fonts, that is kind of the standard size, and then we want to have a heading in 140% of that value, we are not going to have a 22.4px font available. This does now explicitly exist in the font system, so the result will be a rounded value: 22px in this case.

However, if we tell the browser to prioritize the geometric accuracy, we are forcing the browser to scale the text in a fluid way, without any rounding. So, we can really have a heading in 22.4px if we want to, in case the designer insists. As far as the user is surfing your app using a certain kind of browser, since this is only possible in WebKit engines. Gecko browsers apply this value as an optimizeLegibility.

In case you want my opinion, I don’t think geometric precision is really interesting, except for the cases where we really want to create an accurate masterpiece of texts aligned to the millimetre -which, by the way, would probably not make any sense in responsivecontexts-.

Comparing: optimizeSpeed VS optimizeLegibility

To close this text-rendering topic, let me show you a code example to present the subtle bu existing differences between these methods:

<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Corben&family=Raleway:wght@300&display=swap" rel="stylesheet">


<div class="wrapper-demo">

<div class="corben">
  <p class="render-speed">TI Ti ff fl ffi st ct.</p>
  <p class="render-legibility">TI Ti ff fl ffi st ct.</p>
</div>

<div class="raleway">
  <p class="render-speed">LYoWAT - ff fi fl ffl</p>
  <p class="render-legibility">LYoWAT - ff fi fl ffl</p>
</div>
  
</div>

.wrapper-demo > * {
  padding: 20px;
  font-size: 24px;
}

.wrapper-demo p { margin: 5px 0; }

.raleway {
  font-family: "Raleway", sans-serif;
}

.corben {
  font-family: 'Corben', cursive;
}

.render-speed {
  text-rendering: optimizeSpeed;
}

.render-legibility {
  text-rendering: optimizeLegibility;
}

You can also find this codepen link to play around and tests different fonts if you like.

Text-rendering alternatives

What we’ve just seen is pretty cool but, let’s be honest, in most of the cases the default text-rendering options will be more than enough for us to render texts. Still, what can indeed be useful for us is to be able to control manually and for a precise situation to show all the legibility improvements of a type font.

If we want to have ligatures for a certain font in a certain place, we force them. We don’t like the kerning in one of our font types? We can remove it. Both things, individually. For that, we don’t need to affect the global text-rendering. We can just resort to other proprieties we have in CSS3. I’m talking about: font-variant-ligatures and font-kerning.

There is something even more powerful for the font families we use. The expert level is using the property font-features-settings, from which we can enable and disable the font features without any limitations.

It is not a well-know propriety, nor is it used widely because usually,font-variant properties are more semantic and easy to remember and apply than font-feature-settings. I invite you to chek them out. You’ll probably discover a lot of things you didn’t know you could do with your fonts, just by changing some classes in your stylesheet!

That will be all for today in this brief typo tip! I hope you enjoyed it and it was interesting to you.

See you next time!