Beefing Up Dull Text in WebKit

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.

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.

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.

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!

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.

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?

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).

What you call “dull” text in the headline is just sharp, evenly weighted, crisply antialiased text.

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.

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.

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.

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)