In our pages, it is often the case that the text or border in an area becomes particularly blurred during display, as follows (the data has been desensitized) :

Normally, this would be the case:

Emmm may not be obvious in the big picture, but let’s take a detail comparison and it will be very intuitive:

When is this phenomenon triggered?

So? When does that trigger the problem? In fact, we can find a lot of similar cases on Google, to sum up:

  1. When some ancestor container of the text element existstransform: translate()ortransform: scale() 等 transformThis problem is easy to occur during operation

Of course, this is only a necessary condition, not a sufficient one. Digging deeper, it turns out that some other conditions must also be met:

  1. The element workstransform: translate()ortransform: scale()The resulting calculation results in a non-integer value

For example, the CSS code triggered by the above case is as follows:

.container {
    position: absolute;
    width: 1104px; 
    height: 475px;
    top: 50%;
    transform: translateY(-50%);
    // ...
}
Copy the code

Because the height of the element is 475px, translateY(-50%) equals 237.5px, which is not an integer, leading to the blurriness of the font inside.

However, it is important to note that not all generated non-integers result in internal font blurring.

Here’s a simple hint:

Again, when the height was adjusted from 477px all the way up to 469px, only 477px and 475px caused blur, while 473, 471 and 469 did not. So, this is just a necessary condition for ambiguity.

  1. Whether the text content is blurred also depends on the screen, it is not easy to trigger under hd screen (DPR > 2), and more likely to happen under normal screen (DPR = 1).

In the process of my actual measurement, I also found that this phenomenon basically only happens under the ordinary screen with A DPR of 1.

High-definition screens, like the MAC’s, are less likely to trigger this problem.

DPR = Physical pixel/device independent pixel, indicating the device pixel ratio. This has to do with what we call a Retina screen. The device pixel ratio describes the initial ratio of physical pixels to device-independent pixels in the unscaled state.

  1. Not all browsers behave this way, it basically happens in the Chromium kernel.

Why does this happen?

So why does this happen? No special official answer has been found to this question, which is widely believed to be because:

Because the browser split layers onto the GPU for 3D conversion, rather than integer pixel offsets, Chrome is not as accurate when rendering fonts.

For those of you interested in this question, take a look at these two discussions:

  • Chromium Bugs — Issue 521364: Transformed text at fractional offsets is very blurry.
  • Serious bug: Slick Slider turns off subpixel font rendering on the entire site in Chrome #2275

How to solve it?

So how can we solve this problem? One solution offered by the community:

  1. Setting elements-webkit-font-smoothing: antialiased

The Font-smooth CSS property is used to control the smooth effect of font rendering. This feature is non-standard and should be avoided in production. And in my test, this method is not very effective.

  1. Make sure you use ittransform: translate()ortransform: scale()The elements of are even in height and width

If you give the element an explicit transform value, such as the one I used to center the element horizontally in the example above — transform: Translate (-50%, -50%), making the element even in height and width works, but if you can’t determine the value of transform, for example transform: translateX(-31.24%) or transform: translateX(-31.24%) Scale (1.05) ‘, then this method still doesn’t work.

  1. deprecatedtransform

If the problem is fatal to your page, ditch Transform and find an alternative. Most of the time, there are alternatives that don’t use transform.

To sum up, this paper simply explores the phenomenon of internal text ambiguity caused by the use of transform in the Chromium kernel, and gives some solutions that can be tried. In fact, more debugging is needed to try the optimal solution.

The last

Well, that’s the end of this article, I hope you found it helpful 🙂

Want to Get the most interesting CSS information, do not miss my public account – iCSS front-end interesting news 😄

More interesting CSS technology articles are summarized in my Github — iCSS, constantly updated, welcome to click on the star subscription favorites.

If there are any questions or suggestions, you can exchange more original articles, writing is limited, talent and learning is shallow, if there is something wrong in the article, hope to inform.