Yup - for me, each ascender of an "h" is a line of red pixels next to a line of blue, no actual black at any point.
Removing the unnecessary font-weight CSS makes it better. Personally I also find it more readable if I remove the font specification and let it fall back to Serif, and it also takes up less vertical space, but that's a matter of personal taste. Not tried it on mobile.
> Yup - for me, each ascender of an "h" is a line of red pixels next to a line of blue, no actual black at any point.
Each of your pixels is made of a tiny red, green, and blue pixels. The 'black pixel' is the gap between the red and blue sub-pixels (the green being off is black.)
100% contrast. People went to great effort to achieve the highest possible contrast in print, e.g. with barium sulfate coated paper, optical brighteners in paper, single-use carbon film typewriter ribbons, oil based inks so pigments could be used instead of dyes, etc. Contrast is good. The only good reason I can think of to use less than 100% is for syntax highlighting.
This text looks okay to me even if I manually adjust the gamma to approximate doing antialiasing/compositing in linear space. It’s on the thinner side, but plenty readable.
Which platform has “correct” font “blending” (and what do you mean by “blending”)? I have not yet heard of one which does antialiasing or compositing of fonts or other vector graphics in linear (vs. gamma-adjusted) space. The font hinting / antialiasing on Windows is super ugly. Linux varies a lot from one machine to the next and a long history of various font problems.
Maybe what you meant was “looks OK on the Mac with more-correct-than-usual font blending, and looks terrible on X other platform”?
More likely what you meant was “looks OK on a Mac with a high-resolution display (typical of recent Macs), but is harder to read on a lower-resolution display (still common among budget PCs).”
Macs do weird stuff with font compositing, try toggling subpixel rendering in CSS [0] and watch the weight of your type completely change. :- )
Whatever they're doing, at least one of these modes has to be wrong.
Windows is a complete mess when it comes to text display, but that's nothing new, although to be fair to them, they do not screw this particular thing up.
FreeType2 in Firefox or a Chromium-based browser on X11/Wayland is spectacular, especially following the expiry of many ClearType-related patents, and the Adobe's contributions; with the various fontconfig settings which change the output, it doesn't noticeably change the weight (for a given size) for modes that people actually want to use (nobody's going back to v35).
OSX has an interesting approach, and if they could resolve their blending/filtering/rasterization/whatever (god only knows where their problems lie) problems; a lot of people like the tradeoff of legibility for accurate text sizes in a given weight, and that's OK.
[0]: Usually accomplished with -webkit-font-smoothing: antialiased or -moz-osx-font-smoothing: grayscale
CSS rules to disable subpixel rendering (because OSX still doesn't do it right) are littered all over the internet. Here's a random blog post from the front page of HN which has it applied to the body text probably because OSX made the text look inexplicably terrible for no good reason by default:
http://ajroach42.com/floppycasts-1-44mb-podcasts/
There's a reason this CSS property doesn't actually do anything on other platforms.
https://contrast-ratio.com/#black-on-rgb%28246%2C%20246%2C%2...