How to prevent Webkit text rendering change during CSS transition

CssWebkitCss TransitionsCss Transforms

Css Problem Overview


I'm using CSS transitions to transition between CSS transformed states (basically transitioning the scale of an element). I notice that when the element is transitioning, the rest of the text on the page (in Webkit) tends to slightly alter its rendering until the transition is done.

Fiddle: http://jsfiddle.net/russelluresti/UeNFK/

I also noticed that this does not occur on my headers, which have the -webkit-font-smoothing: antialiased property/value pair on them. So, I'm wondering, is there any way to have the text maintain its default look (the "auto" value for font-smoothing) and not alter rendering during a transition.

I've tried explicitly setting the text to use the "auto" value, but that doesn't do anything. I should also note that setting font-smoothing to "none" also prevents the rendering blink during transition.

Any help is appreciated.

Edit 1

I should note that I am on OS X. While looking at my test in Chrome on Parallels, I did not see the two different paragraphs behaving differently, so this may be an issue exclusive to Macs.

Css Solutions


Solution 1 - Css

I think I found A solution:

-webkit-transform: translateZ(0px);

Forcing hardware acceleration on the parent element seems to solve the problem...

EDIT As commented, this hack disables font-smoothing and can degrade text rendering depending on your fonts, browser and OS!

Solution 2 - Css

UPDATE August 2020

You no longer need to target Safari with a media query to enable subpixel font smoothing. The default is fine.

However, although it uses subpixel font smoothing by default, there's a significant fly in the ointment in Chrome's font smoothing, for anyone looking for a consistent rendering of text.

  1. This is Chrome's rendering of light text on a dark background light on dark
  2. This is Chrome's rendering of dark text on a light background dark on light

Look at the size of the whole in the letter e above. The Light text on a dark background is rendered with a perceptibly heavier weight than the dark text on a light background (with identical css font styling).

One solution, for sites respecting the user's dark / light theme setting, is to target Chrome with a media query that is limited to dark mode and switch it to non subpixel smoothing like so:

@media screen
and (-webkit-min-device-pixel-ratio: 0)
and (min-resolution: 0.001dpcm)
and (prefers-color-scheme: dark) {
  body {
    -webkit-font-smoothing: antialiased;
  }
}

The result :

dark on lightlight on dark antialiased

A far more consistent text weight regardless of whether rendering light on dark or dark on light.

Check out the side-by-side comparison of before & after: light on darklight on dark antialiased

--

UPDATE May 2018

-webkit-font-smoothing: subpixel-antialiased now has no effect in Chrome but in Safari it still improves things a great deal BUT ONLY ON RETINA. Without it in Safari on retina screens text is thin and insipid, whereas with it, text has the proper weight. But if you use this on non retina displays in Safari, (especially at light weight values) text is a disaster. Strongly recommend using a media-query :

@media screen and (-webkit-min-device-pixel-ratio: 2) {
  body {
    -webkit-font-smoothing: subpixel-antialiased;
  }
}

Explicitly setting -webkit-font-smoothing: subpixel-antialiased is the best current solution if you wish to at least partially avoid the thinner antialiased text.

--tl;dr--

With both Safari and Chrome where the default font rendering uses subpixel-antialiasing, any CSS that forces GPU based rendering, like the suggestions above to use a transform using translateZ or even just a scale transition, will cause Safari and Chrome to automatically "give up" on subpixel-antialiased font smoothing and instead switch to just antialiased text, which looks a lot lighter and thinner, especially on Safari.

Other responses have focused on maintaining a constant rendering by simply setting or forcing font-smoothing to the thinner antiailiased text. To my eye using translateZ or backface hidden significantly degrades the quality of the text rendering and the best solution if you want the text to just stay consistent and you're OK with the thinner text is just to use -webkit-font-smoothing: antialiased. However, explicitly setting -webkit-font-smoothing: subpixel-antialiased does actually have some effect - the text does still change slightly and is just about visibly thinner during transitions rendered on the GPU but not as thin as it goes without this setting. So it looks like this at least partially prevents the switch to straight antiailiased text.

Solution 3 - Css

I've noticed that pretty much every time I'm having graphics issues (flickering/stuttering/choppiness/etc) due to a transition, using -webkit-backface-visibility: hidden; on the elements that are acting up tends to solve the problem.

Solution 4 - Css

To prevent text rendering changes due to hardware-acceleration, you can either:

  1. Set all text to -webkit-font-smoothing: antialiased. This means text is thinner and not sub-pixel antialiased.

  2. If you want text which is being affected by hardware-acceleration to be sub-pixel antialiased (the default kind of font smoothing), then putting that text inside an input, without borders and disabled, will keep that sub-pixel antialiased (at least on Chrome on Mac OS X). I have not tested this on other platforms, but if sub-pixel antialiasing is important, you can at least use this trick.

Solution 5 - Css

If you're using Firefox on a Mac you'll want to use the following css to fix the issue.

-moz-osx-font-smoothing: grayscale;

More on this at https://stackoverflow.com/questions/11459746/css3-webfont-smoothing-and-antialiasing-in-firefox-and-opera

Solution 6 - Css

This is what worked for me. Hope it helps. Found in other stackoverflow post.

-webkit-font-smoothing:antialiased;
-webkit-backface-visibility:hidden;

Solution 7 - Css

To prevent the rendering change you need to set font-smoothing: antialiased (or none).

The browser disabling subpixel font rendering is likely a side-effect of hardware acceleration. When the background you are rendering against is constantly shifting, the text cannot be rendered on a separate layer, as each frame must be checked against all background layers. This could severely degrade performance.

Apple often disable subpixel font-smoothing on their own sites.

Solution 8 - Css

In addition to the above solutions (-webkit-transform: translateZ(0px) on the element, and -webkit-font-smoothing: antialiased on the page) some elements may still behave badly. For me it was placeholder text in an input element: For this, use position:relative

Solution 9 - Css

I had the same problem. Read it carefully:

> I notice that when the element is transitioning, the rest of the text > on the page (in Webkit) tends to slightly alter its rendering until > the transition is done.

none of the solutions above seemed to work. However, setting (things like)

#myanimation { -webkit-transform: translateZ(0px); }

on the element that has the animation did work.

By taking the animated element to the GPU layer you take it out of the normal flow of the page rendering (things like z-index will not work anymore too, for example). As a side effect, the animation and the rest of the page wont influence eachother anymore.

If it effects your font rendering, it only does so for the animated element, ofcourse. I don't see the difference in my Chrome.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionRussellUrestiView Question on Stackoverflow
Solution 1 - CssArmel LarcierView Answer on Stackoverflow
Solution 2 - CssatomlessView Answer on Stackoverflow
Solution 3 - CssJordan BorthView Answer on Stackoverflow
Solution 4 - CssJoran GreefView Answer on Stackoverflow
Solution 5 - CssleclaeliView Answer on Stackoverflow
Solution 6 - CssDaniel AlmeidaView Answer on Stackoverflow
Solution 7 - CssHenrikView Answer on Stackoverflow
Solution 8 - CssWraithKennyView Answer on Stackoverflow
Solution 9 - CsscommonpikeView Answer on Stackoverflow