I wrote two posts on the topic of WebKit font smoothing before, but unfortunately the situation has grown worse since then. In allowing the designer to pick their own font smoothing mode with the -webkit-font-smoothing CSS property, WebKit developers have opened up an opportunity for typographic abuse, namely, the disabling of subpixel font rendering. As I mentioned before, WebKit gives designers three font smoothing modes:
- Nothing, which gives you jagged fonts
- Subpixel-rendering, i.e. the default font smoothing mode that is used for most other stuff on your desktop OS (mobile devices don’t use subpixel rendering due to having to suport both vertical and horizontal screen orientations)
- Antialiased, which disables subpixel-rendering and smoothes the font on the level of the pixel, as opposed to the subpixel.
Why the choice? Subpixel rendering gives us optimal font clarity for your typical dark text on light background. However, on Mac OS X, when this is reversed and you set light text on a dark background, you get a fairly ugly effect where the text becomes overly bold, spilling out of its lines. Switching away from subpixel rendering to antialiasing for light text on dark backgrounds makes it look lighter, countering the bolding effect. There may be other uses such as fixing font smoothing issues on custom fonts on Windows, or simply using it for the effect that it creates on small bits of text, headings or interface elements.
Abusing antialiasing
Designers, having received a new property to play with, began to use the antialiasing mode everywhere on their text, even for large portions of dark text on light backgrounds. Disabling subpixel rendering made that text look different, more slender and without any hint of subpixel discoloration. Because of this, at first glance, antialiased text appears to look better than its subpixel sibling.
But upon closer inspection, antialiased text is always blurrier than subpixel rendered text. This is not a matter of opinion, it’s just how the rendering works. Subpixel rendering utilizes each of the three individual subpixels in every pixel of the screen to smooth out and sharpen the edges of the font. Antialiasing relies on whole pixels only, which effectively reduces its smoothing sharpness by three times. Wikipedia has a great page on subpixel rendering if you want to learn more about how it works.
Here’s a screenshot of the two modes, showing both, dark text on a white background and white text on a dark background:
Antialiased text looks more slender and because it has less pixels to play with, so instead of spilling out to more pixels it tries to fit in less. Unfortunately, unless the font is very well optimized to fit into each pixel, it will still spill out into adjacent pixels, causing it to have blurry edges, as well as giving it a weak, washed-out look. In constrast, subpixel rendered font will use adjacent subpixels, rather than whole pixels, leading to more refined, clearer edges and stronger lines.
The sharpness of subpixel rendered text makes long portions of body text more readable. Light text on dark background, at least on OS X, is the opposite. Subpixel text tends to spill out and make the font appear bold. Here, the antialiasing mode actually becomes useful in helping refine the lines.
It’s not a “fix”
I was recently looking through the code of Skeleton, a beautiful boilerplate for responsive site design, and noticed that it too had fallen for the antialiasing trap. The font smoothing property was placed in the body selector to style everything on the page, and beside it was a comment that said: “Fix for webkit rendering”.
The antialiasing mode is not a “fix” for subpixel rendering – in most cases it’s a handicap. Subpixel rendering is technically superior, clearer, and more readable than antialiasing because by utilizing every one of the subpixels it increases its effective resolution used for font smoothing by three times. Antialiasing is useful for certain circumstances, such as for light on dark text, but it is absolutely not a replacement for subpixel rendering, and certainly not a “fix”.
Why do designers keep misusing it?
I have two theories for why people keep misusing antialiasing. The first is that they focus too much on elements on the page as merely elements on the page, things to be moved around and laid out. They focus too much on building a hierarchy of elements with tools like contrast levels, disregarding things like readability of the text in the process. The second reason follows from the first and is to do with how the designer tests their site, which they do by using things like the “squint” test, without also trying to actually use it by reading the text. Let’s talk a little bit about each one of these.
The contrast mistake
In web design, contrast is a useful tool for building a sense of hierarchy between the elements on the page. Highest levels of contrast are reserved for the most important elements making them stand out, while elements of lesser importance are given lower levels of contrast, making them fade into the background. In this way, the designer catches the eye of the user and directs it to what they consider most important, while pushing all the other extras into the background.
The prevalence of washed out, light gray fonts used for body text is in part a misapplication of this contrast technique. The designer assumes that the headline is most important, then the author, then the date, and then, when they finally get to the text, they give it a low level of importance and style it in a low contrast gray. They are catering for the skimmer, the reader who looks over the content, searching for specific things, perhaps scanning a list of headlines to find the article they want, and in doing so demote the importance of the actual text, since a long blob of text is not part of that skimming mode.
While applying varying levels of contrast to the elements on the page is important, the body text is a special kind of element that is in most cases exempt from this technique. Body text is supposed to be read, so above all, it must be legible and readable. This means large font sizes, clear typefaces designed for the screen and healthy levels of contrast. Applying antialiasing instead of subpixel rendering makes the fonts less crisp, and removing contrast by using light grays makes it unreadable. It doesn’t matter how well defined the hierarchy for the rest of the elements is, unless the actual content is readable the design has failed.
The squint test mistake
When the designer has finished laying out their site, they test it by either moving back away from the monitor to see it from afar, or squinting their eyes slightly to see a more blurry picture. The squint test helps you see the hierarchy, organization and separation of elements on the page by seeing what stands out and how the elements chunk together when viewed with a quick glance.
This test is useful for for interface design, but it is completely useless when testing the readability of the page. To test readability of the body text there is only one thing you can do without using additional testers, and that’s to actually read the text.
Throw away your “Lorem ipsum” and populate the text with something real if you haven’t already done so, and when you’ve styled it, try to actually read it. I find that it helps to read different portions of text whenever you change the typography because once you’ve read something, you’ll already know how it goes and so will coast through it. To test readability, you have to try and actually read the text using the typeface and font styling that you’ve selected. There is always a difference in readability, and you’ll instantly feel it. Yes, the difference is often very slight, but you should be able to tell if your changes have made an improvement or not.
Designers who merely style their content but do not try to read it don’t concern themselves with whether or not it is actually readable, only with whether or not it looks good from a distance. They care only with how well the composition of the page works, how well the elements are aligned, how well they’re styled and how well the hierarchy between them is defined. But while all that is good, the most crucial aspect is forgotten, for unless the actual text on the page is readable, all the rest of it won’t matter.
Please stop “fixing” WebKit font smoothing
So here is yet another plea for designers to stop “fixing” WebKit font smoothing by disabling subpixel rendering. Feel free to use it on light text on dark backgrounds, feel free to use it to fix custom font rendering on Windows or to style specific bits of text on the page to make it look more slender, but for main portions of text where readability is paramount please leave the default setting alone and let the operating system handle the smoothing.
〈자료출처- Please Stop "Fixing" Font Smoothing – UsabilityPost〉