Bug 69214 – Font rendering issue when using opacity in CSS with Google Web Fonts

• Status: UNCONFIRMED
• Component: New Bugs

[T.J. Barber]

Ok, so I've found this bug on both Ubuntu 11.04 running Chrome 14 and Mac OS X 10.7 running the latest nightly build of WebKit (latest as of today, being October 1, 2011. http://www.webkit.org/quality/bugwriting.html reports WebKit 535.6+).

So I use Google Web Fonts a good bit when I'm designing a website, and for the past two websites I've created I have had a lot of problems with them and the opacity CSS property under any WebKit based browser. Here's a look at my CSS code so you know what I'm talking about: 

#navbar a {
	font-family: 'Tangerine', cursive;
	font-size:40px;
	color:black;
	text-decoration:none;
	opacity: 0.5;
	  -webkit-transition: opacity .25s linear;
	  -moz-transition: opacity .25s linear;
	  -o-transition: opacity .25s linear;
	margin:12px 16px;
	display:inline-block;
}
#navbar a:hover {
      opacity: 1;
}

What usually happens is one section of a character gets cut off until you hover over the element and allow it to fade in. When that happens the rest of the character comes up on the screen. I started fiddling with '#navbar a' in Element Inspector and set the opacity to 'opacity: 1;" and the issue obviously goes away. I checked under Gecko-based browsers and the issue didn't exist, and I also ran it through the W3C CSS Validator. It isn't my code.

I set up an example page that you all can access by going to http://jfc.winworldblog.com/. You'll see the issue on "Gallery" and "Contact" links. 

To a designer, it's a serious problem because it really looks terrible. Thanks for your time, and I hope this can be fixed soon. =)

This is essentially bug 6274. On OS X, you can work around it (at a considerable performance cost) by specifying "text-rendering: optimizelegibility;" for the text in question.

[HerrSiering]

I've come across a very similar issue but couldn't find anything related except for this bug, so I'll put what happens for me into this one as additional information.

The scenario is similar to the one described here: I animate the opacity of a link (white) on hover. It has 0.75 opacity and an opacity of 1 on hover. The font is Fira Sans. Changing to e.g. -apple-system does not change the behaviour, though.

The rendering in Safari macOS (Version 11.1.1 (13605.2.8)) is very thin compared to other browsers. This is happening on 1x resolution displays, on retina displays the font display is fine.

My guess at what is happening here:

My understanding is that Safari uses -webkit-font-smoothing: subpixel-antialiased as the default for rendering fonts. Which works great as long as you don't run the setup described above – opacity > 1, 1x resolution display. Then, some pixels are not rendered as font but rather as background, which results in a font display that rather reminds me of back-in-the-day IE6 font rendering than an optimized font.

Which would explain why this issue does not show up with higher pixel density. There are simply enough pixels present to warrant a good font display.

Using text-rendering: optimizelegibility; did not fix this. I also tried using -webkit-font-smoothing: antialiased – but that changes the font rendering in Chrome (Version 67.0.3396.87 (Official Build) (64-bit), but I guess that doesn't matter) to a too thick font display on macOS, unfortunately.

I was not able to find any further information anywhere on solving this :(

Since this bug is rather old: Will this be addressed or will this stay as is?

[HerrSiering]

Here's a tweet containing a screenshot of the font rendering in Safari and Chrome: https://twitter.com/HerrBertling/status/1011636509013835778

(In reply to HerrSiering from comment #2)
> I've come across a very similar issue but couldn't find anything related
> except for this bug, so I'll put what happens for me into this one as
> additional information.

What you are describing is different from what’s reported in this bug. Please file a new, separate bug for that.

[HerrSiering]

Done, thanks for the hint :) https://bugs.webkit.org/show_bug.cgi?id=187090