This is how kotlinlang.org looks like when I load it in Chrome, -webkit-font-smoothing is set to ‘none’:
This is how it looks like if I uncheck this style in Chrome’s web inspector:
Which do you think looks better?
EDIT: please click on the screenshots to see the full image.
With webkit-font-smoothing disabled (on retina), the site looks absolutely terrible. It looks like a geocities page with Netscape Navigator from 1998, only missing the blinking text and midi.
Looking at the images it looks like the way Linux font rendering used to look if you didn’t enable the “patented” interpreter - only in the US and that patent has expired now. What is the actual machine you’re running on and try to manipulate the font used?
Macbook pro with most recent versions of chrome and macos. But this has nothing to do with the machine.
The os matters as it generally is used for font rendering. In this case it seems that the rendering happens at the virtual (96dpi) resolution instead of the actual one (300-ish dpi). This can lead to bad artifacts if the two are not multiples and there is no reason to do so (it looks like a misfeature/bug in either Chrome or macos)
You are looking at it from a technical perspective, and may be right. However, from a user perspective, I haven’t seen this issue on any other website in about two weeks browsing the web since I noticed the issue on kotlinlang.org.
I remember when Chrome hard crashed a tab every single time when our 3D charts animated; everybody blamed the charts, while the issue was Chrome interpreting values in a typed array as pointers. Whoever is to blame, this issue makes kotlinlang.org look bad, and it can be solved or worked around by kotlinlang.org authors.
I think the OS is pretty irrelevant here. A CSS directive has been added to tell the font renderer – wherever that responsibility lies – to render text without any antialiasing, and the results are poor. It seems incorrect to me to blame the OS font rendering for doing what it has been told to do.
The only justification for the change seems to be one person preferring it, and one link to a blog post from 2012 about why this setting should be used when rendering light text on a dark background on low-DPI screens (which is fairly irrelevant to a dark-on-light website’s CSS settings for high-DPI screens).
Why is this the way it is?
The os makes a big difference as especially with a retina display one would expect little jaggies even without smoothing (due to the high dpi). All platforms have different rendering paths for fonts so the problem is likely unique to mac. I agree though that wherever the problem ultimately lies, jb can work around it. The problem however is more subtle than just “disabling font smoothing is bad”
