Safari bug: text suddenly appears bold after css animation completes (antialiasing change)

Safari has an anti-aliasing issue that’s been around for a LONG time and it seems everyone is content to use an ugly workaround.

i’m just finishing up a site that makes use of the nice Wow.js & Animate.css combo. while doing final cross-browser checks i noticed Safari giving an abrupt change in text style as the fade-in finished.

see the video demo below of Safari versus Chrome, or view this fiddle in Safari:


the heart of the matter

the root cause is Safari’s default text anti-aliasing method is subpixel-rendering, yet it can’t support that method while doing CSS animations. the renderer falls back to traditional anti-aliasing, temporarily creating a much thinner font appearance. when the transition completes it looks as if the text suddenly becomes bold.

admittedly the effect is pronounced in my example because i’m using a thin font and an oblique style. i also realized with some testing that it’s hardly noticeable with a standard black text on a white background. perhaps that’s why no-one is complaining very loudly.

i was surprised to see it’s been a bug with WebKit since at least 2009! rather i should say a bug within the WebCore portion as Chrome and other browsers using Blink no longer suffer from it.


complacency abounds

html { -webkit-font-smoothing: antialiased; } – that’s what everyone’s doing. the “antialiased” value seems to be what Safari uses during the animation, so setting it permanently does prevent the abrupt change.

however… font rendering is a contentious topic. a LOT of time is been spent talking about it (here, here, here, here, etc.). there are even entire research papers on how the matter.

i happen to agree with Mr. Fadeyev and his article Please Stop “Fixing” Font Smoothing. mainly just for consistency since Chrome, Firefox, and Safari all look pretty much the same when left alone to their subpixel predilections.



in my scenario setting font-smoothing to antialiased resulted in extremely thin looking, slightly jagged text in Safari and needlessly hosed the text in Chrome as well. i really didn’t like shotgunning the entire page with this hack.


i know what you’re probably thinking – but the graphic designer in me says “one does not simply change the font!


can we do better?

i came up empty-handed searching for a true fix.

i did find a simple way to use the workaround only in Safari so that Chrome and Firefox can still look as expected: -webkit-backface-visibility: hidden;

yep, that old trick will keep the text rendering with traditional anti-aliasing even after the animation finishes so there’s no wacky sudden bolding. the text still looks too thin and jagged for my tastes, but only in Safari at least. note that any of the tricks to force hardware accelerated rendering of an element will actually work.

i chose to only apply the workaround to my problem elements:

.wow.animated {
    /* prevent abrupt change in smoothing when animations complete (only in Safari) */
    -webkit-backface-visibility: hidden;

that approach might look strange in some designs since the same font will then seem to have 2 different styles. in my case, the animated elements were visually distinct from the rest of the page.

if you’re using CSS animations, especially fades, then for now you just have to decide which is the lesser evil – thin jagged text or sudden bolding.

hey Apple, stop stretching the iPhone and fix this bug already!



related bits

testing was done with latest versions of the 3 major browsers in OS X 10.9.4. i avoided discussing any Windows based browsers because i only had a virtual machine install of Windows handy (Parallels). i wasn’t sure if that environment would render the same as on a native PC.

Safari 7.0.6 (9537.78.2)

Firefox 32.0.1

Chrome 37.0.2062.120

say something about this post

  • (will not be published)

one response to “Safari bug: text suddenly appears bold after css animation completes (antialiasing change)”