Using Chrome Version 40.0.2214.111 (64-bit) on OSX Yosemite, the main site does not render the bold tag correctly. It does however, render correctly on Meta.

FF 35.0.1 on the same system works correctly.

In the screenshot below, the top line should be bolded. I duplicated the line without the bold styling to demonstrate the (lack of) difference between the rendering of the two.

top line should be bolded.

  • 1
    This 'feature' has been bugging me for years.
    – BESW
    Commented Mar 2, 2015 at 20:44
  • I thought I was going crazy today when I was looking at a few posts in chrome. "I know I had bold tags in here before!"
    – phantom42
    Commented Mar 2, 2015 at 20:51
  • Chromium 40.0.2214.111 (64-bit) on Ubuntu renders bold correctly on the main site and here
    – Izkata
    Commented Mar 3, 2015 at 3:57
  • Another user experienced this the other day. Using Safari. No one has any updates do they?
    – AncientSwordRage Mod
    Commented May 12, 2015 at 6:19
  • Related: stackoverflow.com/q/1631033/1075247
    – AncientSwordRage Mod
    Commented May 12, 2015 at 6:50
  • What about what's described here? I've recently hit the same bug in webkit with CSS animations, and this sounds like the same problem as here.
    – Izkata
    Commented May 17, 2015 at 6:56

1 Answer 1


I’m not sure if this is really an answer or not, but here goes …

This would appear to be due to some kind of error or non-compliance in the font itself.

The font varelaround-regular-webfont.woff is correctly fetched (obviously, since the font does show up) from its location on cdn.sstatic.net, but for some reason, Chrome does not render its bold version correctly. There is, at least sometimes, a difference, but it is not all that clear:

Example of bold vs. non-bold on Chrome

The last line there is bold, the rest regular. You can see that the bold is kind of ‘fuzzier’-looking. (This is a screenshot from Chrome 42.0.2311.152/64-bit running on OS X Yosemite.)

With other fonts, including Orbitron Medium (the font used for the main navigation menu (“Questions”, “Tags”, “Users”, etc.), switching font-weight: bold; on and off in the browser shows a distinct difference in boldness:

Orbitron Medium, non-bold (non-bold)
Orbitron Medium, bold (bold)

Well … more distinct, anyway, but I’m willing to believe that’s more down to the font than the browser: the level of distinctness between Orbitron Medium bold and non-bold is the same in Chrome as in other browsers. So it’s just Varela in particular, which tends to be a good indicator that the error is in the font, and Chrome is just less forgiving than other browsers.

Obviously, I don’t know where we’re getting our fonts from ultimately; but if whoever packaged Varela Round to the WOFF format that’s read by both Chrome, Safari, Firefox, and Opera (at least on OS X Yosemite) is actually someone from SE, rather than, say, someone from FontSquirrel, then it might be possible to have a look to see if there’s something non-compliant going on somewhere in the WOFF file (and, presumably, in the base font as well).

An alternative solution might be to make a separate @font-face inclusion call to include the actual bold version into the same CSS font. But since there seems to be only one weight of Varela available, that’s probably not a solution.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .