I am definitely willing to invest time into fixing this, so I would be quite glad about help. My first guess was to serve a heavier font-weight to Windows machines, but Warnock Pro sadly doesn’t have a 500 font-weight available, and instead goes directly from 400 to semibold (600), which is quite a bit too bold, even for Windows machines.
I’ve also experimented with all of the font-rendering and font-smoothing options, but none of them seemed to help.
So, here’s the easiest and most flexible way to do this. This will depend on you being able to serve slightly different CSS to different clients (there are, of course, any number of ways to do this—server-side according to user agent, via JS, etc. etc., so I’ll leave that part up to you).
What you’re going to want to do, to “bulk up” the rendering of the text on the offending clients, is to add this to the post body:
text-shadow: 0 0 0 rgba(0,0,0,0.87);
That’s right: a zero-offset, zero-blur text shadow. The alpha value should be at most equal to the alpha of the text color itself, though you’ll want to adjust it for different combinations of browser/OS. (For example, Chrome on Linux seems to render thicker/darker than Chrome on Windows, so you may want to set the alpha for the text shadow to be much lower for Chrome-on-Linux clients; and Firefox is different, etc.)
This lets you correct for rendering differences across browsers/platforms in a very fine-grained way.
So, it’d be really nice to be able to use the text-shadow trick (I really want to be able to adjust how post-titles look slightly to improve the overall site contrast)
It’s the sad case that while this trick looks excellent on my high resolution macbook, it looks kinda pixelated and cruddy on my desktop monitor. I’m curious if you’ve looked into that at all.
I sure have. What you do is, you use the resolution media query to set different styles for hi-DPI and low-DPI devices (I use a threshold of 192ppi, which includes all Retina screens from Apple, and all 4K monitors I’ve seen, and of course all smartphones from the last 5 years or something).
Then, as I said, you may want to serve slightly different CSS to Linux/Windows clients, and also use another media query to adjust things for Firefox, etc.; adjusting the alpha of the text shadow is the easiest way to do this tweak. (Whether it will in fact be necessary will of course depend on details; you can test that on the platforms/browsers in question and use your judgment.)
Then, you’ll want to provide an exception for Safari (setting for it the same style as you use for the low-DPI displays for Mac clients—regardless of target device), because (so far as I am aware), Safari’s text-shadow support is still buggy. (See, e.g., this GW style sheet, and Cmd-F “Compensating for Safari being terrible”, to see how to target Safari to make such an exception.)
Warnock Pro sadly doesn’t have a 500 font-weight available, and instead goes directly from 400 to semibold (600), which is quite a bit too bold, even for Windows machines.
Oh, I hadn’t realized it literally didn’t exist (as opposed to we didn’t happen to load the 500 weight version). It’s actually been grating on me a bit that the bold is a bit too bold, and this moves me towards interest in a different font rather than fixing Warnock.
(On my shortform feed awhile ago Said had some additional thoughts on using bold for skimmability that might be worth revisiting if we’re thinking about fonts more seriously)
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:
The first font’s “Regular” and its “Bold” differ only mildly, whereas the second font’s “Bold” is massively heavier than its “Regular”
The first font’s “Regular” is about as heavy as the second font’s “Light”, and its “Bold” is comparable in weight to the second font’s “Regular”
(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-weight values according to the established convention of “Regular” = 400, “Medium” = 500, etc.), then setting the CSS font-weight property of your text to, say, 500 offers 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-face rules 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 CSS font-weight values, 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-face rules: you can take advantage of CSS features like unicode-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, whereas unicode-range also 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.
I am definitely willing to invest time into fixing this, so I would be quite glad about help. My first guess was to serve a heavier font-weight to Windows machines, but Warnock Pro sadly doesn’t have a 500 font-weight available, and instead goes directly from 400 to semibold (600), which is quite a bit too bold, even for Windows machines.
I’ve also experimented with all of the font-rendering and font-smoothing options, but none of them seemed to help.
So, here’s the easiest and most flexible way to do this. This will depend on you being able to serve slightly different CSS to different clients (there are, of course, any number of ways to do this—server-side according to user agent, via JS, etc. etc., so I’ll leave that part up to you).
What you’re going to want to do, to “bulk up” the rendering of the text on the offending clients, is to add this to the post body:
text-shadow: 0 0 0 rgba(0,0,0,0.87);
That’s right: a zero-offset, zero-blur text shadow. The alpha value should be at most equal to the alpha of the text color itself, though you’ll want to adjust it for different combinations of browser/OS. (For example, Chrome on Linux seems to render thicker/darker than Chrome on Windows, so you may want to set the alpha for the text shadow to be much lower for Chrome-on-Linux clients; and Firefox is different, etc.)
This lets you correct for rendering differences across browsers/platforms in a very fine-grained way.
So, it’d be really nice to be able to use the text-shadow trick (I really want to be able to adjust how post-titles look slightly to improve the overall site contrast)
It’s the sad case that while this trick looks excellent on my high resolution macbook, it looks kinda pixelated and cruddy on my desktop monitor. I’m curious if you’ve looked into that at all.
I sure have. What you do is, you use the resolution media query to set different styles for hi-DPI and low-DPI devices (I use a threshold of 192ppi, which includes all Retina screens from Apple, and all 4K monitors I’ve seen, and of course all smartphones from the last 5 years or something).
Then, as I said, you may want to serve slightly different CSS to Linux/Windows clients, and also use another media query to adjust things for Firefox, etc.; adjusting the alpha of the text shadow is the easiest way to do this tweak. (Whether it will in fact be necessary will of course depend on details; you can test that on the platforms/browsers in question and use your judgment.)
Then, you’ll want to provide an exception for Safari (setting for it the same style as you use for the low-DPI displays for Mac clients—regardless of target device), because (so far as I am aware), Safari’s text-shadow support is still buggy. (See, e.g., this GW style sheet, and Cmd-F “Compensating for Safari being terrible”, to see how to target Safari to make such an exception.)
Oh, I hadn’t realized it literally didn’t exist (as opposed to we didn’t happen to load the 500 weight version). It’s actually been grating on me a bit that the bold is a bit too bold, and this moves me towards interest in a different font rather than fixing Warnock.
(On my shortform feed awhile ago Said had some additional thoughts on using bold for skimmability that might be worth revisiting if we’re thinking about fonts more seriously)
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:
The first font’s “Regular” and its “Bold” differ only mildly, whereas the second font’s “Bold” is massively heavier than its “Regular”
The first font’s “Regular” is about as heavy as the second font’s “Light”, and its “Bold” is comparable in weight to the second font’s “Regular”
(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-weight
values according to the established convention of “Regular” =400
, “Medium” =500
, etc.), then setting the CSSfont-weight
property of your text to, say,500
offers 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-face
rules 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-weight
values, 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-face
rules: 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-range
also 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.