While doing a bit of cross-browser poking around on CodePen, I noticed that the font for the code editors was notably duller and weaker in WebKit browsers (Safari and Chrome) than it was in Firefox or Opera. I quite like Chrome and it was sad to me knowing that I would be spending a lot of time looking at inferior looking text, so I set about looking for solutions.
Here’s the “before” shot:
There used to be a text-shadow trick, but that has since stopped working and was actually for making text thinner, not beefier. Then there is the -webkit-font-smoothing stuff to play with. But no dice there. The value none looked gross and there was no visual difference between antialiased and subpixel-antialiased in this case.
The answer came on Twitter, as usual!
@chriscoyier try -webkit-text-stroke: 0.35px
— Kevin Ennis (@kevincennis) July 11, 2012
Adding this to the text noticeably beefed it up. Still not quite as bright and sharp as Opera or Firefox, but closer. And since the effect is applied with a -webkit- vendor prefix I didn’t need to worry about it affecting the other browsers.
I was all proud that this would solve the issue and all would be lovely. Of course I wake up to an email like this:
Hey,
I have seen the change to the text on Chrome and it really gives you a headache, it’s so blurry.
Ah, the internet. Whattyagonnado?
Update
Feedback from this has been about 50/50. Some people hate the “faux bolding” (I don’t think this is really faux bolding but I understand), some people prefer the thin text, some people preferred the attempt at brightness.
Here’s the scoop. The thin text from the very top screenshot wasn’t a result of “That’s just how WebKit does it”, it was because an element within the same parent element of the text had a CSS 3D transform applied to it. Namely, transform: translate3d(0, 0, 0). The great irony here is that that code was applied in order to prevent text from getting that “thin” look when a CSS transition was taking place, a curious side effect of CSS transitions. While it worked, it also caused the text in the editor to get that “thin” look all the time.
So, in CodePen, I’ve removed the -webkit-text-stroke so the text rendering looks way better and more comparable with Opera and Firefox. I’ve then more carefully applied the 3D transform fix to other elements that need the help during transitions.
make a poll! i vote for the brighter text :)
If/when webkit fixes the font rendering, your text will look extra beefy.
Although, I have to agree with the anonymous emailer: I prefer the lighter text. I find it much easier to read.
Hm, I liked it better before, too. If you see it on the real website, not just in screenshots, it’s not dull but thinner. That looks way better. Cleaner, less cluttered. And in addition it’s better readable because of this reasons!
Yea I also noticed today that text is kinda blurry on Chrome/Windows
I compared the browsers myself now. This is the site without your hack: http://f.cl.ly/items/3n1z1Q1Y2K1u001X1K2W/Bildschirmfoto%202012-07-11%20um%2017.31.42.png
It looks more the same than with you hack enabled. Whats going on with your browsers? :-)
Nice! Now I can try to re-enable graphics acceleration on Isotope.js without worrying for the thin fonts.
Thank you Chris! (And thanks Kevin, of course)
Yep this is a case where the text stroke might be a good idea to have on all the time.
For me Black on a light bg usually was ok but normally I’d use the text shadow thing when white on dark to help with better contrast and making it ‘pop’ just a little. Kevin Ennis suggestion of:
-webkit-text-stroke: 0.35px
seems a nice subtle approach
Had a good laugh after reading this :D
Really interesting way to improve the text readability. However, I confirm the blurring of the text .
I usually go with:
-webkit-font-smoothing: antialiased;
and, as a complement, I add this too:
text-rendering: optimizeLegibility;
I tried both of those things and neither of them affected the thin text. It turns out a faux 3D transform was affecting the text, check out the update above.
Can you please tell me what font you are using for the font in Firefox?
The text not only looks thinner, also much narrower. It looks almost like it is a different font. Actually the font used for the code is definitely different on Chrome in your screenshot.
I’d vote for not messing with the font rendering, I think it is one of those quirky things we just have to deal with and hope that the browser vendors improve it.
I preferred it slightly duller too. Easier to read : )
Is this one of those things where you might need to worry about Opera supporting the webkit prefix and having the text at the desired beefiness level to begin with?
Here’s a with/without from Chrome on Windows:
http://bit.ly/MkWAjN
Definitely blurrier, which is saying something since text is usually super aliased on Windows.
Yikes. I’d say they are both kind of crappy and would have trouble choosing. Fortunately you shouldn’t have to, see the Update above.
Tell me about it. I have to break our designer’s hearts every time I show them what happens to their carefully chosen type on a Windows machine. Alas.
Definitely a Windows issue, because of the text rendering (GDI) that Chrome uses.
Cap: http://i.imgur.com/WCQaz.png
The bottom is much more inline with MacOS text, so probably doesn’t look weird to those used to the OSX approach. But on Windows, it’s definitely jarring when the rest of the text (not only in the OS, but even the rest of the text on the page) is rendered the standard way.
You could write a win|mac|xnix class on the html tag after a bit of OS detection (http://www.javascripter.net/faq/operatin.htm). Curious to see if you think it’s worthwhile… especially given the possibility that your user stats probably heavily favor Mac users.
Let us know what you decide!
Danny
I would actually be interested in seeing the numbers on which OS visits csstricks most. Maybe Chris could tell us the ratio of Windows / Mac visits. I would have guessed he would have more windows users visit his site, seeing as how Windows is so much more wide spread than Mac. Chris?
I didn’t know off-hand, so I looked it up:
Windows 61.81%
Mac 27.00%
Linux 8.09%
iOS 2.25%
Android 0.59%
The quoted email is right. What you call “dull” text in the headline is just sharp, evenly weighted, crisply antialiased text. Messing with text stroke is just another faux bold technique and completely rapes the nice, sharp rendering in WebKit. It’s kind of like Subpixel Rendering got wasted in a bar and threw up all over your monitor. Please, please, PLEASE just say “no” to faux bold.
I think of Faux Bolding as when you are applying font-weight: bold; to a font that doesn’t offer it and so the browser takes over and fakes it. Modern webkit won’t even allow you to do that anymore. (It will however to faux italic).
I don’t think so. It turns out that text is totally fucked up “faux thinned” text that is the result of a WebKit bug where text elements appearance during transitions or that are near 3d transforms.
This seems like a perfect real world example of progressive enhancement. You try to fix one thing just to find you break another. :D lol
Did you think about an increase in font size? In my experience white type always reads better if it’s slightly larger than the black on white equivalent. Plus larger type always reads easier than smaller bold type.
An alternative trick is to increase line-height slightly.
Do you have screenshots of the results on a windows machine? I wonder how well windows will handle the rendering of the stroke.
oh nvm, I just saw one of the comments above…. damn Windows =\
Tried it on a couple of my sites, found that darker backgrounds is really the best place to use this.
Nice post. Very useful information for enhancing readability of text.
I wrote an article on using this same technique a while ago. I use it to faux-antialias poorly rendered typekit text.
To get it right for an entire site, you have to do a good few levels of settings, and tweak until they look right.
Also, bear in mind that the result can be very different on a PC.
Owen
I’ve found that Firefox does a noticeably better job at rendering text than webkit, specifically in the areas of weight and kerning. Hopefully webkit will improve since font rendering is a critical function.
Wow, Really excellent work. We can do anything with css, thanks for sharing your experience.
It looks like you want a semi-bold weight, actually. What I’ve been doing lately is specifying the following:
font-weight: 600;
For better or for worse, non-WebKit browsers, at least at the time of this writing, will only render it as bold. Only WebKit-based browsers understand more than 2 font weights (normal and bold). For what it’s worth, I think Safari renders text the best, followed by Chrome. The rest are like bulls in china shops. For example, look at the text “HTML” in the panel’s heading in the graphic: perfectly proportional and handsome in Chrome and Safari, grossly overweight in FF and Opera.
Perfect article, works here.. (thanks)
Its a nice solution, I’m undecided on whether I like it though, especially as extra thin fonts are becoming more popular. Looks like a good solution to make thick(er) H tags look smoother though as fonts always look grainy on Chrome (Windows)
I don’t want to be mean, but the screenshots are pretty much worthless because they’re jpegs with compression artifacts. With something as delicate as font rendering it’s uncompressed or nothing.
Worked like a charm to fix the pixelated font in chrome. Thank you.