(Probably not interesting to 90% of people, but would love to get input from our local typography nerds)
We've been using Warnock Pro as our default font for body-text and content-related elements for a while, and I've been quite happy with it on my Mac, but on Linux on Windows machines the font renders as a bit spindly and thin, and can be hard to read at some smaller font-sizes.
Given that we've been refactoring a bunch of our Typography anyways, it seems like the best time to maybe switch to a new font. In most typography-matters I tend to defer to Butterick's Practical Typography who has a good set of recommendations for fonts similar to Warnock, and my favorite one I've found so far is Butterick's one creation Valkyrie. So changing to that seems like a thing we might do in the next few weeks.
Stylistically, my favorite font continues to be ETBook, but that one sadly has a variety of rendering issues that make it impossible to use on Lesswrong. Valkyrie is about as good as Warnock in that respect, but renders much better on Windows and Linux machines in that respect, but I would love to hear recommendations for other fonts if people have any good ones (commercial fonts are fine, as long as they don't come with weird "amount of user" limits).
Belated comment on this particular aspect of the problem:
It is an unfortunate fact of digital type design that the mapping between “which of the weights that this font comes with are called ‘Regular’ or ‘Medium’ or ‘Semibold’ or ‘Heavy’ etc.”, and “how thick the letterforms actually are / how heavy does the text look when rendered in that weight” is… horrifically inconsistent from font to font (even among fonts from the same designer or publisher!). In other words, you can easily find two fonts such that one or both of the following hold:
(And don’t even get me started about inconsistent weight naming! “Regular” vs. “Book”; what the heck is “Medium”; “Semibold” vs. “DemiBold”; is “Heavy” heavier than “Black” or vice-versa? etc., etc.)
The consequence of this is that if you use the publisher-provided CSS files for fonts (which map designer-provided weights to CSS
font-weightvalues according to the established convention of “Regular” =400, “Medium” =500, etc.), then setting the CSSfont-weightproperty of your text to, say,500offers you no guarantee of how heavy the text will actually look! (This is compounded, of course, by the fact that not all fonts—much less all digital releases of fonts—come with all nine of the “standard” weight grades.)And this is why I write my own
@font-facerules for every one of the fonts I use. I never use the publisher-provided ones; I look at each font I use, and I determine a custom mapping from provided weights to CSSfont-weightvalues, and write the CSS to define that mapping. This lets me guarantee a much greater degree of consistency when switching fonts, or using alternate fonts for different client platforms, etc. (Of course, this does require hosting the font files myself, rather than relying on a service like Google Fonts or TypeKit; but that is easy.)(If you’re interested in trying this, I’d be glad to make my custom-written CSS files for many of the popular fonts—such as many of Adobe’s offerings, among others—available to you guys.)
Edit: There are other benefits to rolling your own
@font-facerules: you can take advantage of CSS features likeunicode-range(as explained, e.g., here) to, e.g., specify the use of one font for most of your text but another font for certain mathematical symbols (note that this is different from using font stacks to define a fallback font, as the latter only comes into play if the primary font doesn’t have glyphs for the given characters, whereasunicode-rangealso works in the case where the primary font does have those glyphs, but you don’t like the way they look, or they render poorly on certain systems, etc.). This, too, affords you greater flexibility in choosing which fonts to use.