Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 152304 "-webkit-font-smoothing: antialiased" stopped working in 22.0.1229.79
Starred by 186 users Reported by, Sep 25 2012 Back to list

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Closed: Oct 2012
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression

Sign in to add a comment
Chrome Version       : 22.0.1229.79
OS Version: OS X 10.7.4
URLs (if applicable) :
Other browsers tested:
     Chrome 21.0.1180.89: OK
     Safari 6.0 (7536.25): OK

What steps will reproduce the problem?
Load the website above.

What is the expected result?
Skinny text (before picture)

What happens instead?
Chunky text (after picture)

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4

after - chunky text.png
21.3 KB View Download
before - skinny text.png
23.5 KB View Download
Note that the 'chunky text' is actually the default rendering on OSX, and is especially poor for lighter text on a darker background.  Setting  "-webkit-font-smoothing: antialiased" historically disables the default subpixel antialiasing, triggering  plain antialising instead. 
Many people have relied upon "-webkit-font-smoothing: antialiased" to work around the poor font rendering.

"-webkit-font-smoothing: none;" still seems to work, so the issue is only with "-webkit-font-smoothing: antialiased" and not  "-webkit-font-smoothing" in general.

Comment 2 by, Sep 26 2012
Labels: -Area-Undefined -Type-Bug Area-WebKit Type-Regression WebKit-Fonts
Comment 3 by Deleted ...@, Sep 26 2012
I can corroborate this issue appears in 22.0.1229.79, but appears not to exist in 22.0.1229.79 beta. 

Another example URL:
I get this on Mac too. Bloated text on what was gorgeous looking text.
Comment 5 Deleted
Comment 6 by, Sep 26 2012
Comment 7 by, Sep 26 2012
Can you reproduce it with Chrome Canary, too ?

Download at:

Thanks in advance.
Comment 8 by, Sep 26 2012
I'm seeing it in both Canary 24.0.1278.0 and Stable 22.0.1229.79.

Here's a page where you can see it in abundance in white text on black:
Comment 9 Deleted
Status: WontFix
Note that this is the same root complaint as that of Issue 143733 and the original report of Issue 141425. For more information see Issue 141425 Comment 83.

The webkit-font-smoothing css property is, contrary to the summary, still working. It is still respected, as no lcd font smoothing is being applied. However, the bug where it also affected the weight of the text as a side effect has been fixed.

It appears that what you would like (and possibly others, myself included) is something like a webkit-font-ignore-system-settings-and-draw-from-original-outlines-because-that-is-the-way-it-should-be css property. This is not the intent of webkit-font-smoothing, as it was not the intent of text-shadow or webkit-text-stroke which were previously used for this side effect.

If you find your lcd smoothed text on OSX too heavy, you can reduce CoreGraphic's glyph outline dilation with

defaults -currentHost write -globalDomain AppleFontSmoothing -int 1

in a terminal. The default when using lcd smoothed text is 2.
So your saying -webkit-font-smoothing isn't being ignored and that the problem lies with the OS? The only possible way to get around this is to change AppleFontSmoothing via Terminal? This can't be the only fix for this especially when, Safari renders the same fonts perfectly fine?

I could be going back to using Safari because of this one issue, being a designer, this issue seriously bugs me.
Also note that this change seems to make it impossible for icon font shapes to be rendered cleanly (even when the shapes have been authored correctly with regard to grid alignment, etc).

Attached is a before/after (21 vs 22) of some of GitHub's font icons which they rolled out recently.

Here is a blog post about how the icons were made, including a quick note about their reliance on `-webkit-font-smoothing:antialiased` to achieve correct rendering : 
8.6 KB View Download
@Comment 11 by evan...:

Yes, webkit-font-smoothing isn't being ignored. You can also turn off lcd smoothing on OSX completely from the system preferences (which will also turn off glyph outline dilation). Safari does not render the fonts correctly; toggling between lcd smoothed text and regular anti-aliased text on the same page should be imperceptibly different. Switching rendering modes should not change the outlines.

@Comment 12 by ali:

What you want is the webkit-font-ignore-system-settings-and-draw-from-original-outlines-because-that-is-the-way-it-should-be css property I suggested above. The webkit-font-smoothing css property is not the one you're looking for; the bug in its implementation has been fixed. I would suggest going to and requesting such a css property, or opening a new issue requesting the addition of a 'webkit' prefixed css property of this sort.
Comment 14 by, Sep 26 2012
@Comment 10 by bunge...

Okay, I can understand if the previous implementation had a bug, but the old behavior has been like that for at least a year (probably actually 2) and people have come to depend upon it for their web design. I'd argue that the correctness ship has sailed :)

If you folks are sure you want to break this long precedent, please offer a workaround -- some way to trigger the old rendering. Changing the OS X setting isn't a workaround because that can't be pushed upon our customers.

I don't know if requesting a new webkit prefix is the right thing to do considering Safari still has the old, wrong behavior.
@ Comment 11 by bunge...:

Technical correctness is merely one goal of development. This "correctness" -- which, as you mention, not even Apple's own browser (Safari) adheres to -- has, without any perceptible drawbacks, been the de facto for a very long time. 

So, this "minor tweak" will change thousands of hours worth of hard design work that thousands of web designers have completed... negatively. (On all my tests, fonts look notably worse, not better.)

While I very much appreciate what you have done with Chrome, and in particular your previous response to this thread (which was certainly sensible), I think there needs to be an immediate solution when a change such as this is made.

Granted, no one is owed anything in this world, but I think that's the *correct* thing to do.

I suspect you'll be hearing a lot about this in the coming days. This is not a minor issue. This latest update only applied one hour ago for me.
I would have to agree with jcpar... You might be rendering the fonts the "correct" way now and the blame is to give to OSX... Fine by me... 

But if you look at the reality, the web just got ugly for users under chrome & OSX. That's about it. Bold weight looks so chunky and bad that we would have to change the css of our websites to revert all bold text to regular. Even google page looks horrible...

I really hope you are going to offer a solution for this. It's just wrong. I am personally switching to safari now (I'm a designer can't look at the web like that), but am still dissapointed by this new feature as my designs and site just got ugly for 100% of my OSX chrome users...
@Comment 14 by jcp...:

The correctness ship has been going in circles for some time and seems to be manned by a crazy pirate crew. As noted above, text-shadow and webkit-text-stroke have both been used for this purpose before and been fixed, to the consternation of many.

Note that the change in behavior seen here in webkit-font-smoothing was not the motivation for the change. The motivation for regular anti-aliased text to always match lcd smoothed text was motivated by high-dpi devices, opacity fading, and css animations. Without these two rasterization methods matching there could be quite a 'pop' when there was a forced transition between the two. This has the side effect of fixing the issue where disabling lcd smoothing caused the weight to change, changing the behavior of webkit-font-smoothing.

Note that a webkit-font-ignore-system-settings-and-draw-from-original-outlines-because-that-is-the-way-it-should-be css property would be quite different from the behavior previously seen from webkit-font-smoothing:antialiased. In particular, the browser would be free to still lcd smooth the text when drawing from outlines. The two would be orthogonal.
@Comment 17:

We're not disagreeing with your implementation or the reasoning behind it; what we're saying is that webkit-font-ignore-system-settings-and-draw-from-original-outlines-because-that-is-the-way-it-should-be should immediately be made available as a "Chrome-only" CSS property so that this can all be a non-issue... going through some w3 process isn't the right solution here (for the reasons described above).
Issue 152534 has been merged into this issue.
@Comment 13 by bunge...

> Safari does not render the fonts correctly; toggling between lcd smoothed text and regular anti-aliased text on the same page should be imperceptibly different. Switching rendering modes should not change the outlines.

You are suggesting that the correct behaviour is that a shape should barely change between subpixel-AA and standard-AA (of course zooming in you will see color-fringing on SP-AA)

We are testing rendering text with a native app, and are NOT finding this to be the case. It seems that disabling sub-pixel AA in the app triggers the cleaner non-"dilated" shapes, very similar to last week's stable Chrome.  You are asserting that Chrome < 22 was broken, that Safari is broken, and apparently that native app font rendering behaviour is broken.

Given that this property has been widely adopted and used (abused?) to get decent rendering on OSX, it is very frustrating that the property's behaviour has been abruptly changed without something else being offered up to approximate the effect of the previous behaviour. It seems to me that this change shouldn't have made its way into stable before the mythical `-webkit-f-i-s-s-a-d-f-o-o-b-t-i-t-w-i-s-b` property is available.  

Native text with subpixel-antialiasing enable (default): native-SP-AA.png
Native text with subpixel-antialiasing disabled: native-no-SP-AA.png
Chrome 22 with subpixel-antialiasing disabled: Chrome-22-no-SP-AA.png
118 KB View Download
69.8 KB View Download
146 KB View Download
I'm so sad to see many years of hard efforts made by the google chrome development team behing literally thrown to the garbage due to one small "correction" for a "correct font management".

Let us know when you will consider this as a real bug, in the meantime i'll be hanging with my old rejected friend safari...
This was something of a rude awakening this morning. Chrome is my browser of choice, and we (at Hoefler & Frere-Jones) use -webkit-font-smoothing: antialiased; and -webkit-font-smoothing: subpixel-antialiased; generously and carefully throughout our website and UI. Bulkier type gets antialiased while thinner type keeps the default subpixel-antialiasing. I know I consider this type of microscopic control ideal and was definitely disappointed to see the time we've spent fine-tuning the text on the site go out the window in Chrome.

The aliasing isn't the only issue, though. Not sure if this is related, but we're seeing some other strange issues along with the aliasing. Specifically some strange artifacts in the webfonts that weren't there before today. I've attached two files where you can see the artifacts (n-a.jpg and n-b.jpg).

Another strange thing: Usually when using -webkit-font-smoothing: antialiased; the text will be rendered in grayscale while the text with -webkit-font-smoothing: subpixel-antialiased; (the default) would not. After this lastest update to Chrome the text with -webkit-font-smoothing: antialiased; is still rendering in grayscale but is not actually being antialiased. (see attachment "grayscale.png")
34.2 KB View Download
Let's try those first two attachments again...

In case they're too compressed to view clearly as attachments, you can also view them here:
and here:
2.8 KB View Download
2.8 KB View Download
Comment 24 by, Sep 27 2012
Issue 152421 has been merged into this issue.
Comment 25 by Deleted ...@, Sep 27 2012
I understand what you are saying, the problem is "fixed" in Chrome but I have to agree with other commenters, this is a game changer. The crux of this issue is that web fonts look terrible in Chrome whilst on the same system with Safari 6, web fonts look beautiful and how they should do. Least thats what I'm getting...
I asked James Whittaker, who works on Tweetdeck to capture all current browsers (thx!). Screenshot attached just for reference.
Left to right: Chrome 22, FF 12, Safari 6 & Opera 12.
189 KB View Download
Comment 27 by, Sep 27 2012
I work on, and we use an icon font for various symbols. With default subpixel antialiasing applied, icons look noticably fuzzier. With -webkit-font-smoothing: antialiased; icons in the font look perfectly crisp and pretty. In fact, I was hoping the property would eventually hit IE and Firefox so we could expand the use of the font. It appears though, that icon fonts are useful only in Safari now. Pity, since icon fonts offer us the opportunity to apply CSS shadows, gradients and animation on them, whereas SVG does not yet. 
4.6 KB View Download
Comment 28 by Deleted ...@, Sep 27 2012
I work on We also rely on -webkit-font-smoothing for lighter text on a darker background, such as our navigation. We were sad to see the latest Chrome lose this functionality, whereas it still works in Safari. We understand the reasoning behind it, but it's also an annoying move to just change it and have our Chrome customers (majority of our users) see chunky ugly rendering without offering us another solution.

Attached is our navigation (light text on darker bg) for Chrome, Firefox and Safari on OSX. You can see just how bad it looks on the latest Chrome. My issue though is that even Firefox – whilst not being as nice as Safari's font-smoothing – has better rendering. Look at the 2x version, and the space between the 'g' and the 'e' in 'Manage'...

I'd hope a "fix" would at least offer the same rendering, or that as a browser you would make the text look good as best you can, or offer us designers a solution to a pressing issue. Can you offer us a solution for our customers that doesn't require all of them to change their computer settings?
120 KB View Download
98.2 KB View Download
Issue 152453 has been merged into this issue.
Comment 30 Deleted
It seems that we have reached an impasse in this debate as to whether the degree of control afforded by "-webkit-font-smoothing: antialiased" was a bug or a feature.

bung…, I can see why the issue could and should be treated like a bug: designers started using the property more because they liked the way it reduced the gamma more than they cared whether or not the text was rendered in grayscale or not. They were after the side effect, rather than the effect. You were probably right in fixing it.

Still, given the activity on this thread, and the passion this issue has stirred up in the past 24 hours, I don't think the desire for designers to be able to control the gamma of the text should be ignored. What most of these designers are angry about is that you suddenly took away some of the control that they had over the way their text rendered (and if it is one thing that designers want from browser developers in this day and age, it is more—not less—control over typography).

So, what to do? It seems the problem is mostly semantics; we need to break out the control "-webkit-font-smoothing" gives over the heaviness of the outline in OS X, and put it in a place that makes more sense. In essence, where the control over the level of font smoothing is the effect and not side effect.

What I would like to see would be a CSS -webkit property, like you suggest, that would give designers something equivalent to the "CoreGraphics glyph outline dilation" command that you post in comment 10. Perhaps something like "-webkit-apple-font-smoothing: 1". How can we make this happen? Who do I need to talk to? Would it be possible to give this control on an element-by-element basis?

In regards to the loss of effect of "-webkit-font-smoothing: antialiased", perhaps the "bug" could be reinstated until a "-webkit-font-ignore-system-settings-and-draw-from-original-outlines-because-that-is-the-way-it-should-be" property could be settled on. Designers relied on this trick not only to make the text pretty to look at, but in some cases even to make the text _legible_. Taking this control away without a proper replacement will cause designers to spend hundreds of hours to tweak their sites _just_ so they look passable in Chrome. Some designers probably won't take the time and websites will just look bad in Chrome. I'm sure we're unanimous in this forum that we don't want websites to look bad in Chrome. 

So let's take a step back for a second, re-instate this bug for a little bit, and work on giving designers a solution.
@Comment 20 by a...:
>We are testing rendering text with a native app, and are NOT finding this to be the case.
True, but you cannot rely on this. The dilation behavior is undocumented. This is probably the reason why does not support or document webkit-font-smoothing.

>to get decent rendering on OSX
This statement has been made a number of times, and I'm interested in how bad web developers find the lcd smoothed text rendering on OSX. Is the CoreGraphics lcd smoothed text rendering really considered so bad that 'it breaks the web' and user's settings must be overridden to protect the viewer from it? Is it really imperative that web browsers on OSX support a css property which is effectively only used to make it not look like OSX?

Note that unless you're also platform sniffing, you're disabling lcd smoothing on other platforms like Windows as well.
Comment 22 by dur...:
>After this lastest update to Chrome the text with -webkit-font-smoothing: antialiased; is still rendering in grayscale but is not actually being antialiased. (see attachment "grayscale.png")

I'm unsure by what you mean by 'is not actually being antialiased'; the bottom row of text in "grayscale.png" is anti-aliased (does not have jaggies, is not just b/w).
@Comment 23 by dur...:
I'm not sure which font and settings you're using here, so I'm unsure of the cause. It vaguely looks like an artifact of path dilation (which often has issues with internal pointy bits). If you could provide me with more information I may be able to take a look.
@Comment 26 by paulir..

Heads up that your attached screenshot seems to be scaled down slightly, making pretty much all of the fonts look fuzzy and unclean.

@Comment 32 by bunge...

> True, but you cannot rely on this. The dilation behavior is undocumented. This is probably the reason why does not support or document webkit-font-smoothing

This makes it all the more confusing that you are coming down on this particular side of the fence.  In theory I totally agree that `-webkit-font-smoothing` should not be the place for us to be trying to work around OSXs dilation, but as everyone has said above the fact that it has worked consistently in Safari, Chrome and even native text rendering to achieve that makes it unclear as to why are so adamant on changing the behavior before there is something else that offers similar control in a more documented way.  

If "the dilation behavior is undocumented", what is the purpose is removing the control devs previously had and relied upon? If Chrome 22 is the ONLY example of an implementation that is correct in not un-dilating shapes when disabling subpixel-AA (including native text rendering) can you at least point us toward some discussion or spec which suggests this is the correct behavior? 

> This statement has been made a number of times, and I'm interested in how bad web developers find the lcd smoothed text rendering on OSX. Is the CoreGraphics lcd smoothed text rendering really considered so bad that 'it breaks the web' and user's settings must be overridden to protect the viewer from it? Is it really imperative that web browsers on OSX support a css property which is effectively only used to make it not look like OSX?

In my experience it is most necessary in cases of lighter text on a darker background, which by default become way too overly bold to the point that the shapes are unclear and running in to each other.  A more recent use case seems to be for font icons as mentioned above several times above.  I've attached a few more screenshots of examples of these.

Also, the dilated rendering seems to make it totally impossible to get a clean 1px black text shadow in some cases. Definitely looks broken. See attached: font-comparison-shadow.png 

10.3 KB View Download
8.0 KB View Download
25.6 KB View Download
13.0 KB View Download
13.4 KB View Download
@Comment 28 by mlett...:
I'm going to take a particular look at your case because it is a good example of what was fixed. I cannot access the particular sub-pages of in your screen captures, but the general layout appears throughout the public portions of the site. Note that (at least on the home page) this site is *not* using webkit-font-smoothing for the white on orange header text (in fact I haven't seen it being used at all on this site). Judging from your screen captures it looks like that webkit-font-smoothing isn't being used at all.

It appears that Chrome and Safari went to regular anti-aliased text for the white on orange text due to transparency issues. Firefox did some extra work and decided that it could get away with lcd smoothed text anyway. You will notice that the text in Chrome has the same weight as the text in Firefox, the only difference is that Firefox is lcd smoothed. Safari has the old, un-dilated text, and is much thinner than the other two. What Chrome has done here is see that it was supposed to draw lcd smoothed text, couldn't for technical reasons, so drew the closest possible thing.

For another example of this see Issue 141425 Comment 83.
Comment 38 by Deleted ...@, Sep 27 2012
@Comment 37 by bunge...

Nothing on uses font-smoothing, so don't look that (also that navigation is a sprite image). The screenshots I provided are of the Harvest web application, and the code for the screenshots has "-webkit-font-smoothing: antialiased" on for both Chrome and Safari.

> You will notice that the text in Chrome has the same weight as the text in Firefox, the only difference is that Firefox is lcd smoothed.
> What Chrome has done here is see that it was supposed to draw lcd smoothed text, couldn't for technical reasons, so drew the closest possible thing.

Ok, I get the technical reasons. But it looks really bad, that's not up for questioning. Firefox's lcd smoothed text looks better than the muddy un-kerned and un-sharpened text Chrome is rendering. Can't you fix Chrome's rendering? Why is it that FF has no problem drawing lcd smoothed text, and Chrome "couldn't for technical reasons"? It also seems to _never_ draw lcd smoothed text when light color on dark background.

That doesn't sound 'fixed'. You say you 'fixed' the antialiasing issue, but it just seems like you stopped letting that browser prefix work, instead of putting your efforts into getting the text rendering nicely/properly. Either Chrome should automatically make the text legible (best option), or -webkit-font-smoothing should be reverted until a better option is implemented, or implement a -webkit-apple-font-smoothing option as suggested by in Comment 31.
@Comment 31 by f...:
Thank you for your kind remarks and suggestions.

>You were probably right in fixing it.
I think I mentioned this above somewhere, but I didn't intend to 'fix' this particular bug, it's more or an unintended side effect of fixing issues with layers, high dpi devices, transparency fading, and css animations. I would have no problem backing out the change for the time being if it didn't mean effectively re-opening a number of other bugs and we had a clear path forward.

>control the gamma
Just wanted to make it clear this isn't really a gamma issue. The AppleFontSmoothing property sets dilation of glyph outlines. CoreGraphics normally blits regular anti-aliased glyphs with a gamma of 1.0 and lcd smoothed glyphs with a gamma of 2.0, but this difference is dwarfed visually by the dilation of the outlines. If this were just a gamma issue it would be a lot easier to solve, as there is a knob for that.

>Perhaps something like "-webkit-apple-font-smoothing: 1"
That would be nice, but the setting is undocumented and there is no public api to query the current value nor set the current value for a given call to render the glyphs. I imagine it would be very easy for Apple to expose this if they desired to do so, but seeing as what it is doing is undocumented it seems quite unlikely.

If I had a magic wand, I would prefer Apple changed their implementation. No one seems to like the current CoreGraphics rending of large lcd smoothed text. My guess is that the dilation was added to compensate for the lack of optical variations in current font formats. In physical type the typeface does not scale linearly, the designer or the punch-cutter would make the strokes, serifs, and other features of 'small' strikes relatively heavier in order for the print to be more easily read. And by 'small' it is meant small optical size, which may be 6pt on a phone and 30cm on a billboard. Ink spread also helped with this by providing a small but fixed-size dilation. The current dilation in CoreGraphics appears to be a constant multiplier, dilating the outlines by some percentage regardless of the requested size. Instead, the dilation should be phased out as the optical size increases. There may be issues with doing this (interactive zooming with a combination of pixel scaling and re-drawing might look interesting), but I doubt any of the problems would be as unliked as the current state of things.

That's why I suggested the 'draw from outlines' css property, because we do have some chance of being able to do that.

>until a "-webkit-font-ignore-system-settings-and-draw-from-original-outlines-because-that-is-the-way-it-should-be" property could be settled on

I know I suggested this, but now I'm afraid of it. While it wouldn't be that difficult to implement, it does mean that there would exist a css property which implies a 'CSS Glyph Rasterizer' if you will. It seems very heavy handed to have a property that just says, don't use the system font rasterizer, use this platform independent one instead; more or less a platform wide version of SVG fonts. Most of the web developers here are probably drooling over the mere thought, but it seems like such a thing should not be introduced lightly. The only real argument so far for it is that web developers don't like glyph rendering on OSX.
@Comment 36 by a...:
>makes it unclear
As I stated in Comment 17 and later (more clearly, but after you post) in Comment 39, I'm not really that adamant about changing the behavior, it's just that a more general fix which fixed a number of other bugs has also caused this. Backing out this particular change also means re-breaking a number of other things.

>some discussion or spec
As you quoted, webkit-font-smoothing does not have a specification and is not officially documented in any way. The most 'official' documentation can be found at which states, 'this is non-standard and should not be used.' Correct behavior means not implementing it at all.

>for font icons
As far as the 'webdings' fonts, these would look (almost) the same in a native OSX application if the application respected the platform UI design guide and properly applied the user's settings. The only thing webkit-font-smoothing is doing here is forcing them to lack lcd smoothing.

>impossible to get a clean 1px black text shadow in some cases
Judging by your screen capture, this appears to have a lot to do with hinting and over-draw. On the left button the top edges of the glyphs are right on pixel boundaries, giving a hard edge to the shadow. It looks like on the right (probably due to dilation) the tops of the glyphs do not align with the pixels meaning that the shadow only partially covers the pixels above the final glyph. On top of that the final glyph is overdrawing a good bit of the shadow anyway. From some local experiments, if the text on the right button were lcd smoothed it would look pretty much the same.
Comment 41 by, Sep 27 2012
It sounds like moving forward there are only three options:

1. Revert the change (or have -webkit-font-smoothing: antialiased; trigger something in addition to no lcd smoothing that causes text to be rendered as it was)

2. Keep the change and do nothing else. This leaves A LOT of sites looking terrible in Chrome.

3. Keep the change and add a new vendor prefix that changes hinting/overdraw.

If it were up to me, I would do #1 immediately and phase to #3. Chromium is the leading webkit browser on the desktop and it's not because sites look sloppy in it.
>also that navigation is a sprite image
Yes, the one on the public site is. The white on orange text I was referring to is the text in your screen captures which appears not to be a sprite, since it is different in each of the three browsers. The same comments made about the white on orange text apply to the dark-grey on light-grey text as well.

>for both Chrome and Safari
So you're sniffing Firefox and not passing it webkit-font-smoothing?

Yes, this is a different longer term issue which I am also working towards. Firefox is using subpixel positioning and Chrome is not. I know it looks bad, but it looks bad in lots of places and this change didn't really change that.

> _never_ draw lcd smoothed text when light color on dark background
Well, since it's already linked to from this bug report, has some large white on black which is lcd smoothed.

>letting that browser prefix work
As stated before, this undocumented, unsupported, implementation prefixed css property still works, it's just that the bug in it's implementation which web developers happened to be using in an attempt to control an undocumented feature of CoreGraphics to make text look a different weight than it otherwise would have in order to override the user's local settings, has been changed.

>implement a -webkit-apple-font-smoothing option as suggested by in Comment 31
Please see the last part of Comment 39.
Does the Chrome team actually includes designers?
You seem very concerned by engineering stuff and by applying rules literally (and stupidly) rather than trying to solve designers problems, the people that are trying everyday to make things look good in your browsers.
Even if I'm not a big fan of Apple (the company), this is why I love their products (e.g. Safari). They do care about designers.
Please come back to the previous behavior, even if it seems wrong for you, until you provide a decent alternative!
In the meantime, I'm switching back to Safari (which is not cool because I actually love Google Chrome's features).
Sorry for that comment. It doesn't elevate the conversation but it had to be said.
> As I stated in Comment 17 and later (more clearly, but after you post) in Comment 39, I'm not really that adamant about changing the behavior, it's just that a more general fix which fixed a number of other bugs has also caused this. Backing out this particular change also means re-breaking a number of other things.

I understand that now, and I see how that makes things more complicated.

>As far as the 'webdings' fonts, these would look (almost) the same in a native OSX application if the application respected the platform UI design guide and properly applied the user's settings. The only thing webkit-font-smoothing is doing here is forcing them to lack lcd smoothing.

I'm not sure that makes sense.  Antialiasing, (LCD or regular) should only be present if a straight edge of a shape doesn't lie perfectly on a pixel boundary.  If it does lie on the pixel boundaries the edges should be clean, but instead current Chrome is 'blurring'  hard edges.  I'm guessing that this is because of the dilation that you've mentioned. 

I've attached a Chrome 21 vs Chrome 22 screenshot of one of GitHub's icons, enlarged to easily see the edges.  In both cases "-webkit-font-smoothing:antialiased" was being applied.  On the left the edges are clean, so whatever this property did in V21 allowed the author to align their custom shape to the grid (at a specific font size only).  In V22 the shape is being dilated and there is no way to align it cleanly (and yes, without -w-f-s:aa it would look the same, just with colored blurriness)

As to your suggestion that V22 rendering is the same as native rendering "if the application respected the platform UI design guide and properly applied the user's settings", again we have tested this and this is NOT the case.  Chrome V22 default rendering DOES match native default rendering. But Chrome V22 no-lcd-smoothing DOES NOT match Native no-lcd-smoothing. Screenshots of this attached too.
18.8 KB View Download
9.5 KB View Download
18.9 KB View Download
19.8 KB View Download
Comment 45 by Deleted ...@, Sep 27 2012
Also noticing this issue on many of my sites.  

Referring to post #10: telling us to change our AppleFontSmoothing via the terminal isn't a solution at all. 10 out of 10 of my mac using clients will not understand how to do this. All they want is for the text to look just like the design file, and they expect me to facilitate that. 

I know this is actually a 'bug fix', but it's actually a massive headache, as we have implemented font-smoothing on many, many sites. 
@Comment 41 by jtsut...:

Well, there's always the fourth option of getting Apple to fix this as suggested in Comment 39 section 3. Of course, I'm not holding my breath, but if every developer here complained, maybe they would do something about it. In addition, if they fixed it, everyone would be happy, including the native apps.
Comment 47 by, Sep 27 2012
This is getting ridiculous. Chrome has single handedly undone a massive amount of work put in by designers and dev's across the web over a significant period of time. We understand you guys are aiming for correctness but I urge you to google some of the names that are appearing on this thread. You aren't winning any popularity contests. As an industry we are supposed to be working as a team to provide the best web experience for our customers... the users. I'm also kinda shocked that is the person communicating with the community on this matter. Your answers to legitimate questions and concerns is very dismissive and verging on arrogant. I hope the Chromium team can admit the "fix" was not a "fix" and move forward with one of the many suggested approaches posted previous to my little rant. 
Comment 48 by Deleted ...@, Sep 27 2012
It should tell Chrome devs something that we've [web designers] have always commented on the horrible nature of Firefox rendering in favor of Safari and Chrome. Even if this was seen as a "bug" that wasn't the user perception. Designers LOVE Chrome so give us some slack and help us out here by giving us a way to control this. I'd even go as far as to say we should be pushing Firefox to use the same "bug". 

Hope this gets resolved in the right way because all the hard work on things like Foundation Icon Fonts will be for naught it they look like crap in the browser.
Comment 49 by, Sep 27 2012
@Comment 46

That is the same as #2. Users/Designers aren't going to care who is at fault, they are going to blame Chromium when it has the worst looking font rendering of all browsers.

Furthermore, Apple *shouldn't* change the font rendering if it will affect all native apps. Nobody is upset about font rendering with them.

The world isn't perfect and Chromium is backed into a shitty place here.  Sometimes the doing things correctly is doing things worse.
Comment 50 by Deleted ...@, Sep 27 2012
Comment 39 by bunge... "The only real argument so far for it is that web developers don't like glyph rendering on OSX"

To be honest, the only place I've noticed these issues with glyph rendering on OSX is on webkit browsers, in particular Chrome. All other native apps, etc render just fine. That's why I consider it to be a webkit issue, not an OSX / Apple issue. 
I too have a had over a year's worth of work flushed down the drain in the last 24 hours.  And we've been telling our users Chrome is the browser of choice.  But now I am embarrassed to show our site in Chrome.
Comment 52 by Deleted ...@, Sep 27 2012
This really is sad. Chrome dudes.. were you guys were unaware of the massive degree that the web relies on font-smoothing? if not, why did you push this new bowser update without some sort of alternate method to control the font's weighted appearance? As mentioned in @comment 48.

I build a widely used web font called Pictos:
I also have a font service for web fonts (much like TypeKit). By providing no alternate method of making the fonts look better than default rendering, you have really hosed any and all web designers/developers who use web-fonts. Which is most everyone. Please re-read that last sentence.

When people were told to stop using text-stroke years back, the font-smoothing alternative was immediately adopted by designers & developers around the globe. We have been finding ways to improve default rendering for years and years. Please provide us with a new way ASAP. If you can't, please direct us to the place we can, or maybe setup some thread with Apple that we can all contribute our voice to.

You have the voice, please use it to fix this issue ASAP.

Thanks for making webkit the worlds dominant browser :)

@Comment 43 by vin..:
>Even if I'm not a big fan of Apple (the company), this is why I love their products (e.g. Safari). They do care about designers.

This gave me a small chuckle and a bit of bewilderment. Most here are railing about how terrible CoreGraphics draws lcd smoothed glyphs and how not having a way to override the user's settings and make things look the way they do on other platforms is the end of the web. (Ok, so that might be a bit of hyperbole.) On the other hand, there is this general sense of fondness toward Apple.

To some degree I can understand this, historically Apple has taken the more technically correct route towards glyph rasterization. However, having the platform's public font api always dilate the outlines of glyphs by a constant percentage when doing lcd smoothing is a strange way to care about designers. That Safari happens to have an undocumented feature which can be used for an off-label workaround also seems less than being entirely supportive.

If you remain convinced Apple wants to do right by visual designers in general, ask them to fix it, see Comment 46. While Chrome may or may not end up providing some specific work-around, Apple could fix this for everyone on OSX.
This is embarrassing... I have four websites that rely heavily on "-webkit-font-smoothing: antialiased" and all look absolutely terrible in chrome at the moment. Please revert :(
I'm dealing with the same issue. Fonts look horrible on

Should look like:
Currently looks like:
Comment 56 Deleted
bungeman, I respect your approach and agree, this is inherently an OS X CoreGraphics issue.

Taking all negative comments from some of the commenters on here with a grain of salt, what is the next step that we as web developers and designers should be doing now to our website CSS files make our fonts look the way we expected them to look in Chrome now? (oh and with the fastest possible turn around time)

Is contacting Apple even an option for "fast turnaround"? (if that even exists) 
Comment 58 by Deleted ...@, Sep 27 2012
@Comment 57: "bungeman, I respect your approach and agree, this is inherently an OS X CoreGraphics issue."

Where other than Chrome and Safari have you ever run into these font rendering issues? I certainly haven't noticed it anywhere else. If it's a predominantly webkit based issue, shouldn't the onus be on the browser developers to provide a fix? 
@Comment 44 by a...:
>again we have tested this and this is NOT the case.

Actually, it does. Disable lcd smoothing with 'defaults -currentHost write -globalDomain AppleFontSmoothing -int 0' or uncheck 'Use LCD font smoothing when available' in the Appearance settings of the System Preferences. Then restart Chrome. The user's system settings are respected, and everything is regular anti-aliased and has the weight one would expect.

>But Chrome V22 no-lcd-smoothing DOES NOT match Native no-lcd-smoothing

True, Chrome V22's regular anti-alias when the user's settings are lcd-smoothing does not match native no-lcd-smoothing. In an ideal world, the user's setting of lcd-smoothing could always be respected completely and Chrome would never fall back to regular anti-alias. Sometimes, because of current limitations, Chrome cannot do so and instead uses the closest possible rendering.

It seems you are arguing that what you want is native no-lcd-smoothing. However it appears that what you really want is to force rasterization from unmodified outlines (as would be beneficial to an icon font). However, native no-lcd-smoothing is no guarantee of this, which is why I was proposing a 'CSS Glyph Rasterizer', but see the last part of Comment 39.
@comment 53: I'd like to give a reward to bunge for his highly communication skills. Instead of coming up and smoothing up the atmosphere, he's making everybody feel more irritated by this issue. Do not look more, it is apple's fault, chromuim is right and you are a bunch of ignorant and stupid people just by the fact of using a non standar and recomended call such as font-smoothing....

Now looking at the real facts:

I have many websites that look amazingly bad right now under chrome OSX (behing for some of my sites the mosts used os and browser in the amount of visits). When the user will arrive to the site he will for sure not send me a mail (or to apple) complaining about the fonts looking bad. He'll just feel, after a while navigating, that something is wrong in here. And he'll simply never come back and I'll loose the purpose of my everyday job :)

Right now I am waiting a couple of more days if this issue will be corrected. if not I have not other choice than coming back to the photoshop part, retouch my designs to avoid at all cost using bold types and go through thousands of lines of css. Also start avoiding using @font-face types in the future, since they will surely not be optimized for any native OS... Back to Arial! :)

Comment 61 by, Sep 27 2012
Dear Chromium developers,

I (and EVERYONE else) don't care if the font rendering bug is the fault of Apple, global warming or russian mafia. Safari works fine, so swallow your pride and make it work in Google Chrome too! Or otherwise you just admit that it's ok that your browser suck! Should we stop using your browser?
> True, Chrome V22's regular anti-alias when the user's settings are lcd-smoothing does not match native no-lcd-smoothing. 

I believe that this is the root of the entirety of this issue. 

To be entirely clear when you say "Chrome V22's regular anti-alias" you mean the same as "Chrome V22's NO-LCD-smoothing", correct?   I think the variety of terms can be confusing especially to anyone who is trying to catch up on the situation after the fact. Subpixel-AA = LCD Smoothing.  Regular AA = "Antialiased" = NO-LCD-Smoothing. 

The situation is, more plainly:

* If an OSX user disables "Use LCD font smoothing" in their system preferences (or via the CLI) then they will not see shapes (letters or icons) overly-bolded and blurry in Chrome, Safari, or Native apps

* If the author of a OSX native app disables "LCD font smoothing" for text within their app then the users of the app  will not see shapes (letters or icons) overly-bolded and blurry in that app.

* If a developer set's "-webkit-font-smoothing: antialiased"  (equivalent to requesting the disabling LCD smoothing) on text within a web page, their visitors using OSX and Safari WILL NOT see shapes (letters or icons) overly-bolded and blurry on that page

* If a developer set's "-webkit-font-smoothing: antialiased"  (equivalent to requesting the disabling of LCD smoothing) on text within a web page, their visitors using OSX and Chrome V21 WILL NOT see shapes (letters or icons) overly-bolded and blurry on that page


* If a developer set's "-webkit-font-smoothing: antialiased"  (equivalent to requesting the disabling of LCD smoothing) on text within a web page, their visitors using OSX and Chrome V22 WILL see shapes (letters or icons) overly-bolded and blurry on that page

Can we agree that the above statements are true?

> In an ideal world, the user's setting of lcd-smoothing could always be respected completely and Chrome would never fall back to regular anti-alias. Sometimes, because of current limitations, Chrome cannot do so and instead uses the closest possible rendering.

This is a convoluted and confusing point.  You seem to be referring to a situation that has not even been referenced where Chrome automatically flips over to NO-LCD-smoothing because it can't do LCD-smoothing for some reason, even though the dev has NOT specified "-webkit-font-smoothing:antialiased" and the user has NOT disabled LCD-smoothing on their end.  I don't even see how this is relevant, and I don't think anyone is complaining about this!

> It seems you are arguing that what you want is native no-lcd-smoothing. However it appears that what you really want is to force rasterization from unmodified outlines (as would be beneficial to an icon font). 

No not at all, I would like '-webkit-font-smoothing:antialiased' to render shapes the same way that disabling system LCD-smoothing and restarting chrome does, AKA the same way that disabling LCD-smoothing in a native app does. OR of course, the availability of any new css property or combination of properties that allows us to achieve rendering in this way.
With all due respect to the Chrome development team for creating what is in my opinion the best browser in the world. I feel like things are taking a turn for the worse here. I was surprised to see our consumer-facing website being defaced last morning. These events have triggered 2 questions:

1. How could a 'fix' with such a massive impact like this have been pushed to the stable branch without adequate warning? It seems to me; that said developer should have foreseen that this would visually 'break' many websites, and instead phase in the change in over a course of 2-3 months.

2. What is your definition of correctness in development? It certainly appears caring for customers does not belong to your definition of the word. If so; why even be correct? In this case I believe this not to be the correct decision; because one should factor in the human-side of development too. If your ferrari's engine has been fixed using a piece of duck-tape; do you remove it and break said car because it is correct?

I for one do not intend to 'move' away from Chrome, because our customers won't and Chrome is still the best browser out there. But please; in your definition of 'correctness' factor in the human element a little more and revert this change or give us an alternative.
Comment 64 by, Sep 28 2012
@Comment 32 by bunge...:

Regarding your reply to comment 20 by a..., please note that his native test happened without any change to the AppleFontSmoothing config, that's exactly the default (non-subpixel antialiased) rendering look like in OS X. I did the same test on my machine (also without any change to AppleFontSmoothing) as well, see attachment.

I'm especially confused about your comment "True, but you cannot rely on this. The dilation behavior is undocumented.", because it doesn't not require any undocumented behavior, since it IS the default behaviour.

Also, I'm curious about how Chromium actually rendered the so called unsubpixel-antialiased text. Since it's apparently not the OS native rendering, then you must be using something different than Core Graphics to render it.
Screen Shot 2012-09-28 at 12.32.10 PM.png
50.2 KB View Download
I work on and I was completely caught off-guard by this radical change, can't really believe this is marked as a "Won't Fix", which is really just a slap in the face for all web-developers and designers depending on the workaround.

As being a developer and designer, I'm currently embarrassed by how both JsFiddle and Positionly look under Chrome 22 - I'd like you to take a moment and scan the attachments. Please notice that some words aren't even readable in Chrome 22. The word "Error" looks like "Emon", the words in green sections are barely readable. As noticed by someone above, 1 pixel shadows in most cases are no longer visible.

I believe the whole Chrome dev team is bunch of really smart guys, but it seems they lack to see the impact introduced by this change, and they never discussed any of this with the PR team (I assume there is one).

To me there's only one solution here, the "fix" gets reverted in 23, and we figure out what to do with this from there.
76.8 KB View Download
82.3 KB View Download
Comment 66 Deleted
今天早上打开SF的网站(一个中文IT技术问答社区)   右边的链接变成了发黄的绿色了!我还以为我自己眼花了呢?最后从twitter上面搜索才发现原来是chrome版本更新的问题啊!!! 伤不起啊!!!!

plz Fix this!!!!!Chinese rendering is really appalling ah 

177 KB View Download
Comment 68 by Deleted ...@, Sep 28 2012
I must say that as Web Designer, even if I understand your reasons, it's just turn my websites from beautiful to ugly. And difficult to read, which is the worst, causing users to leave. Thanks.
Comment 69 by, Sep 28 2012
Rather than argue that this change should never be applied, its opponents should be asking that the change be reverted and held in queue for a safer time.

What you've done is punch out the only stable solution to an important problem. What you should do is:
1. restore the solution (revert the change, harming no-one)
2. provide a new solution with an appropriate name (e.g. -webkit-font-rendering: faithful)
3. allow some time for web devs to add this new property
4. finally re-apply the change (restoring correctness without harming anyone)
Comment 70 Deleted
Comment 71 by, Sep 28 2012
Just adding another example of how this change causes a significant degradation in how text is rendered for us. 

We're not asking for much - just that your product continue to behave in the same way it has for years, or that failing that, you provide some sort of work-around that will allow us to recover the previous rendering behavior. 

In general, the response from the chrome team to this issue has come off as pedantic and somewhat obnoxious. Telling us that to be "correct" we should have millions of users  change low level operating system settings rather than provide a constructive remedy isn't helpful. 
11.4 KB View Download
Using windows 7 and since update 22 the most common used font sizes have all become faint and fuzzy. Really impossible to carry on using chrome, if this is not going to be changed. 
Comment 73 by Deleted ...@, Sep 28 2012
Chrome is an amazing browser and I appreciate the weight of these decisions, but with all respect, "WontFix" is a misstep. This thread makes it pretty clear that the only people who think this is a good thing are those on the Chrome team. I've attached yet another example of why this move should be reverted.
Screenshot of Google Chrome.png
41.9 KB View Download
Is there a reason this only seems to be happening with fonts included with @font-face? If I include Helvetica Neue with @font-face in a page I get the crappy aliased text, but then if I disable the @font-face to just go back to a default "sans-serif" system font (Helvetica on Mac), I get nicely anti-aliased text ala Chrome < 22.
@comment 74..
I think this is incorrect, an example I've been looking at (BCC News) is using Arial and is having the same problems.. I may have understood this incorrectly however.. so if this is wrong, I apologise..
Screen Shot 2012-09-27 at 15.19.28.png
106 KB View Download
Comment 76 by, Sep 28 2012
I'd also like to raise my hand in opposition to the WontFix status. Thousands of web designers need to be posting on this thread, because we all noticed it. Our web app got uglier overnight just like the rest of the folks here. 

I'm all for change in the name of progress, even when it's painful, but this change is clearly not progress. Make whatever changes necessary to suit your roadmap and you won't hear a peep from me. I'll manually update everything we have. But don't take a valuable property away for seemingly no benefit. 

For those not holding your breath for this to be fixed, you can apply 400 or 600 weight to any bold text and get somewhat close to the desired result. I had to go through everything we have and manually adjust. It still doesn't look as good, but is better than nothing. 
Comment 77 by, Sep 28 2012
Labels: -Pri-2 Pri-1
Status: Started
OK folks, thanks for the comments here.  We're evaluating what the right course of action is, and will update this bug when there's anything new. 
I'm sorry I agree with the WontFix status. Developers clearly did not understand what webkit-font-smoothing actually did.

Please do not cave to the tyranny of the majority just because they didn't take the time to learn what the CSS rules they use actually are supposed to do.
Comment 79 by Deleted ...@, Sep 28 2012
@comment 78 :

It's not that we don't understand what font smoothing does. We realize that the font rendering on OSX was the unintended side effect of a bug in the webkit-font-smoothing code, and not its purpose.

What bothers us is that there is a long running font rendering issue with webkit and OSX, and no real fix. We used to be able to rely on that hack to get around it, now we don't even have that. 

@comment 77: Thank you for looking into this, much appreciated. 
Comment 80 by, Sep 28 2012
I also raise my hand against the wontfix status.

Not reverting the CSS rule to it's former behavior is one thing,
Removing the opportunity to get an acceptable rendering is another.

it seems to me that CSS has the goal of presenting content to the user (hence the "Style" in cascading style sheets)
Any update that changes the visual appearance of a web page should not be acceptable. If it went into a release version, it has to be considered public and hence stable.

The reasons for the change may be perfectly acceptable from a technical point of view, but css is visual, and technicalities are only secondary here.
The result is akin to pulling the carpet from under the designer's feet, a.k.a not good at all.

Also, we spent years raging against IE having bugs but also a different interpretation of CSS rules.
We finally have browsers that are coming to a consensus.

Please do not force designers to hack something around to get the rendering they want. That goes backward.

Comment 81 by, Sep 28 2012
Labels: ReleaseBlock-Stable
Could this antialiasing change be responsible for link colors in small text being off since v.22?

Have verified this same color abnormality on PC and Mac, Chrome 22 and Canary.
9.4 KB View Download
Comment 83 by, Sep 28 2012
OK folks, a quick update.  For Chrome 22, we're going to work to revert to the former behavior, and we'll be tackling how to fix the bug correctly in a later release.  We don't have a firm time that we'll push the update out yet, stay tuned.
Thanks a bunch. In particular, thanks for putting up with all the crap and drama in this thread.
Comment 85 by, Sep 28 2012
@comment 83:

Excellent, thank you so much, kerz!
Comment 86 Deleted
@comment 83 by

Thanks kerz, it really is appreciated.

Whoa....... hold up.

I thought the bug was now fixed?
Isn't the heavier font dilation expected to exist even when that property setting was set?
Did I not correctly understand that there is no true webkit based rendering solution tied to CSS properties to fix this issue?
Isn't it an OS X LCD font smoothing issue that mac users need to turn off?

Whichever the solution SHOULD be .. I do appreciate the fast turn around. That in itself is commendable.
As a designer, this is really frustrating. I can't claim to understand all the technicalities discussed in this thread, but I do know this...

1). I spend 10 years learning my trade as a designer
2). I work really hard designing some websites
3). I spend countless hours making sure my designs are pixel-perfect on the web
4). Chrome updates
5). All the fonts look s**t in Chrome

I really hope there is some resolution to this soon, as Chrome is my browser of choice, and has been for a long time now, but it will drive me nuts if I have to keep looking at these terribly-rendered fonts!

Comment 90 by, Oct 1 2012
Issue 152604 has been merged into this issue.
Comment 91 by Deleted ...@, Oct 2 2012
I was about to post this… It appears that in Chrome 22 they updated the rendering to not be as harsh on retina screens. I guess the thin fonts we're looking too thin on the retina screens. This update appears to have made the anti-aliasing appear to not have any effect. You can see this by changing from -webkit-font-smoothing: antialiased; to -webkit-font-smoothing: subpixel-antialiased; - it has no effect, but -webkit-font-smoothing: none; none does.

Please fix this!
Issue 153396 has been merged into this issue.
Labels: Mstone-22
Comment 94 by, Oct 2 2012
Labels: Merge-Merged
Status: Fixed
This has landed, and will make it into our next updates for 22 and 23 on their respective channels when released.  Thanks for your patience folks.  We'll have more info about what we plan to do for 24 soon I expect.
Comment 95 by Deleted ...@, Oct 2 2012
Excellent! Thank you very much, and we look forward to the plans for 24.
@ Comment 94:

I would like to extend my thanks to the Chrome team. I, too, will look forward to hearing about the plans for 24. In the meantime, thanks for reverting this issue. When is the release of Chrome 23? November?
This is fantastic news. Thank you very much Chrome team. 
Very happy to hear this. Thanks so much for listening and taking everyone's feedback to heart.
Hooray for sanity!
Big thanks to the Chrome Team for making this decision. It's never an easy decision to scrap legitimately good (in this case technically "correct") work.
Comment 101 by Deleted ...@, Oct 4 2012
Awesome news! Thanks so much for fixing this. Curious, when do you think  22 and 23 will be released?
Agreed.. glad to see something is being done about this.. was driving me up the wall
Comment 103 by, Oct 8 2012
Heads up to folks following along here, the update for 22 with this reverted was just pushed this morning.
Comment 104 Deleted
Comment 105 by, Oct 8 2012
Can you report what version you have now?
Comment 106 Deleted
Comment 107 by, Oct 8 2012
This doesn't appear to be the same problem as mentioned above with fonts being too bold.  Can you file a new bug for this?
Version 22.0.1229.79
And it says it is up to date.

No changes in display; doesn't appear reverted.
kerz, it would help a alot to people following this issue if you told us what version of chrome fixes the issue.  My chrome says it is up to date, but fonts are still fat and ugly.
Comment 110 by, Oct 8 2012
Sure, 22.0.1229.92 should have the update.  If it says you have no update, try restarting entirely (make sure the app fully quits and is not running in the background) and restart.  All stable channel folks are being offered the update now on the Mac.
Was super hoping that the issue of text rendering in wrong/muted colors was related to this, but the update didn't have an affect. Hasn't been much activity on that bug:
I'm not able to get 22.0.1229.92

I have restarted my computer 3 times and Chrome too.  It still says I am up to date with Version 22.0.1229.79

My OS is OS X 10.6.8

How do I get the update?
Same issue as folks above - Chrome isn't showing there's an update available.

That said, I've downloaded Chrome manually, and I can confirm the issue has been resolved. All fonts look as they used to.

Thanks a lot for this kerz!
Comment 114 by, Oct 9 2012
Interestingly today's minor OS X update for 10.8.2 seems to have fixed this issue for me, without having had to install an update for Chrome...
Comment 115 by Deleted ...@, Oct 9 2012
I was also experiencing this issue with Chrome 22.0.1229.79 on OS X 10.8.1 and 10.8.2. Chrome wasn't showing any updates available but like others I just re-downloaded Chrome and replaced it. It now reports the version number as 22.0.1229.92 and the issue is resolved.
Comment 116 by Deleted ...@, Oct 9 2012
Noticed rendering issue has different behavior on https:\\ vs Http:\\ loadings.
Designed website with Questrial that looks great on https: test server, but pixelated on normal http with Chrome and IE7
There is a new update for Chrome
Version 22.0.1229.92

It fixes this problem.

I had to download Chrome again and reinstall in order to get it to update.


Comment 118 Deleted
I am not happy with this change. Now fonts look thin when antialiased fonts are used compared to subpixel-antialiased fonts. This makes any text that "fades out" go thin, which is very jarring.

Example: (view on Chrome Mac)

Notice how the second line of text is horribly degraded. Before this change the text looked identical. This change forces developers to use text-stroke hacks to regain the same thickness when using opacity on fonts.

This is a really stupid decision.
Comment 120 Deleted
Here is a screenshot of before (top text) and after (bottom text) on Chrome Mac 22.0.1229.92.

I defy anyone to say the bottom text looks better!
19.6 KB View Download
Thank you for the fix! At least for us, the problems we had are now gone and we're back to beautifully rendered glyph fonts, and nice rendering of Helvetica Neue and others which we use in our apps and which we had problems with lately. Thanks!
@Comment 119  and 121 by

The issue you describe is what Chrome 22 was trying to fix, but that change was backed out of 22 and 23 due to -webkit-font-smoothing:antialiased and this issue specifically. A means of satisfying both is now in the latest Canary for Mac 24.0.1291.1. Starting with this Canary, regular antialiased text will match the lcd smoothed text, except when -webkit-font-smoothing:antialiased is used. (As a side note, this also applies to 'canvas'.)
@comment 123 Thanks for clarifying, Chrome Mac 24.0.1291.1 looks good, especially on canvas elements and opacity as you mention. M24 can't roll around soon enough!
I'm still seeing wrong color reproduction in both latest stable and canary builds. In my case, #1564c2 (used both for the link and the thick border below) has a purple tint when displaying text.

Setting -webkit-font-smoothing: antialiased fixes the perceptible color but text becomes too thin.
4.8 KB View Download
5.5 KB View Download
8.5 KB View Download
Comment 126 by, Oct 17 2012
Please, take a look at the issue #155462, which I think is the same like this one but it is happening on Windows.

I started to dislike Chrome as fonts are so ugly.
adding html, body { -webkit-font-smoothing: subpixel-antialiased !important; } to Chrome's and/or Chrome Canary's Custom.css is temporary fix. Hope this issue gets resolved one way or another.
Comment 128 by, Oct 29 2012
@Comment 127: It does not work in my Chrome 22.0.1229.94 on Windows 7 x64.

Any help how to fix this so annoying thing?
The chromium team still did not confirm issue #155462.
Comment 129 by Deleted ...@, Nov 1 2012
Version:22.0.1229.94 m
Windows 7 64 bit SP1
I am having the same issue the text looks distorted
23.1 KB View Download
adding html, body { -webkit-font-smoothing: subpixel-antialiased !important; } to Chrome's and/or Chrome Canary's Custom.css, can not fix to me.
anyone know why?
Comment 131 by, Nov 20 2012
Still happening for me. I've switched to Opera but I would like to see this resolved.

Windows 7; Chrome 23.0.1271.64 m

The 'good' text is IE. The 'bad' text is Chrome.
261 KB View Download
Hi, we have a similar issue, reported on #161734

Have you tried with an external monitor? 

On the same MBP, if we use an external display fonts are ok. Then we can move the chrome window back to MBP's display and it will be ok too. But as soon as you stop using the external display fonts becomes ugly.
Comment 133 by Deleted ...@, Dec 22 2012
This extremelly ugly font rendering still exist in Chrome 23 on Windows 7 x64. See the attached screen for Segoe rendering (the left one is IE9, followed by FF, right one is Chrome).
104 KB View Download
Comment 134 by Deleted ...@, Jan 2 2013
on chrome 24 and still the fonts are poor on most sites.
Comment 135 by Deleted ...@, Jan 11 2013
I was also having this issue - I thankfully found a solution to the text flickering and wanted to share it in case anyone else was having similar troubles. My issue was when trying to have a jQuery wordpress slide show play with transition animations, and experiencing the webkit bug doing the text thinning during those transitions.

I've found this text issue happening only on Mac in both Chrome and Safari - it turns out it is a well known bug with the webkit engine for Macs, where it is trying to optimize the performance and causes a thinning of text in and sometimes to peripheral text / text around the slideshow, on the slide areas. That's what makes the flickering happen during animations and transitions. 

To FIX this issue, you need to add some code to the CSS style sheet.

This is the code I added to fix the flickering - note - this fixes it in both Chrome AND Safari - but for me, it added some additional issues in Safari, which I will explain after this:

body .site {
-webkit-font-smoothing: subpixel-antialiased !important;
-webkit-backface-visibility: hidden;
-moz-backface-visibility:    hidden;
-ms-backface-visibility:     hidden;

This should make sure text smoothing looks good but also the key part is that -webkit-backface-visibility: hidden; line - THAT will be what really helps smooth out the flickering of text.

BUT while seeming to fix it completely in Chrome, it caused a few issues for me in Sarafi. I've added some CSS elements in my Child theme to customize my theme and these elements are positioned with CSS using z-index positioning to fall OVER the slide show. Well, once applying this fix, the elements I had made over the slideshow were now flickering as the active slides moved over the top-positioned elements temporarily during transition, I guess because they were becoming active and adding that webkit fix had disabled it looking like it was staying in place. But, I found out by adding the line of code below to the elements I was wanting to stay in place and NOT get covered / flicker, it worked to fix this issue too:

-webkit-backface-visibility: hidden;

If you add that line of CSS to the elements in front of the slideshow it will make sure your image slides don't pop to the front and cover these top elements.

Now my text is no longer looking flickery on my slide transition animations. Hope this helps someone else!
Comment 136 Deleted
Comment 137 by Deleted ...@, Jan 17 2013
Hi All,


It seems like this is especially (but not always) an issue when @font-face is being used. If you're a developer using font replacement with something like Font Squirrel try putting the .SVG format immediately after the .EOT IE fixes. This immediately fixed the rendering for me and doesn't require any further fixes.

I know this doesn't help everyone but hopefully someone will find it useful.

#137 I applied this fix and was happy for a while.. until my colleagues experienced content overlaps, shifts and weird behavior. And doesn't happen all the time, only from time to time. Looks like it has to be changed back. 
Project Member Comment 139 by, Mar 9 2013
Labels: -Area-WebKit -Type-Regression -WebKit-Fonts -Mstone-22 Cr-Content Type-Bug-Regression Cr-Content-Fonts M-22
Project Member Comment 140 by, Apr 5 2013
Labels: -Cr-Content Cr-Blink
Project Member Comment 141 by, Apr 6 2013
Labels: -Cr-Content-Fonts Cr-Blink-Fonts
Comment 142 by, Jun 28 2013
font-face rendering in chrome is an embarrassment on osx and windows with font-face. 

using svg for font-face helps, at the cost of it being slightly less efficient. wott is not working well though.

really hope this get some chrome devs attention. 

BTW: Of course its a none-issue on a retina-like high-dpi display. but most actual users dont have that yet.
Comment 143 by Deleted ...@, Jun 28 2013
#138 Yep, same for me. Used that fix, and I get different render results from time to time. As I can see it happens only when I use "float: right" or "text-align: right".
16.0 KB View Download
Comment 144 Deleted
Comment 145 Deleted
Comment 146 Deleted
2014. Still the same issue. Shame of the 21st century that Chrome developers force anti-aliasing upon us. I have found NO SIMPLE AND SUITABLE WAY turning this 5h1t off. By 5h1t I mean the WebKit font smoothing. Looks ugly, makes the text more unreadable, consumes a lot more resources. Thank you for the bloat! Please provide me a way to REMOVE THIS!
I'm using Wordpress & the Google font Raleway and a user send me the attached example how it looks like on his site.

18.7 KB View Download
Sign in to add a comment