TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Browser Font Rendering Inconsistencies

88 pointsby jermieralmost 5 years ago

14 comments

crazygringoalmost 5 years ago
Summary: if you&#x27;re specifying a bold font style (700) but not supplying a bold version of the font (only 400 and 600), Safari creates a &quot;faux bold&quot; on its own, while other browsers fall back to the next-closest weight (600).<p>Neither behavior seems more obviously correct, since you&#x27;re asking for something that doesn&#x27;t exist.<p>Moral of the story: whenever you&#x27;re using webfonts that come in a variety of weights, make sure you&#x27;re loading font files in the weights you&#x27;re intending to use! Otherwise behavior may vary.<p>(And in contrast to multiple comments here, this has <i>nothing</i> to do with macOS using different&#x2F;darker types of antialiasing than other operating systems. That is not what this article is about.)
评论 #23775540 未加载
threepioalmost 5 years ago
The problem arises when you&#x27;re invoking a style (like `h1` or `h2`) that by default requests a bold weight, but the `font-face` declaration only supplies a WOFF declared &quot;font-weight: regular&quot;. In that case, the browser will try to synthesize a bold style by &quot;smearing&quot; the regular.<p>One fix for this is to set heading tags to &quot;font-weight: normal&quot;.<p>Another fix is to supply two `font-face` declarations for the same WOFF file, covering both regular and bold, so that when the browser asks for the bold version, it just gets the same thing.<p>(Strictly speaking, I would classify this as user error, not a browser flaw, though it&#x27;s an easy mistake to make)
评论 #23775797 未加载
评论 #23773831 未加载
评论 #23775184 未加载
评论 #23773804 未加载
tinus_hnalmost 5 years ago
Why would it be a bug if two browsers don’t render a h1 element the same, if you don’t specify how you want it to look?
评论 #23774916 未加载
kanoboalmost 5 years ago
Maybe related — there was a Chrome bug regression that was recently fixed that rendered the thickness of font-sizes above a certain threshold incorrectly, large bold text wouldn&#x27;t be bolded - <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=1057654" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=105765...</a>
tomc1985almost 5 years ago
Damn it folks, stop trying to make your designs pixel perfect!<p>There will <i>always</i> be font rendering inconsistencies. It&#x27;s how the web works.<p>&gt; The cross-platform problem is a harder one to solve as you can&#x27;t control how the operating system handles font rendering.<p>Bingo.<p>So stop trying! Embrace flexible designs and differences in rendering
评论 #23775709 未加载
评论 #23781930 未加载
aahhahahaaaalmost 5 years ago
These rendering differences also impact vertical alignment with specific fonts, which will absolutely drive you mad if you&#x27;re trying to troubleshoot.<p>Take a look at Github&#x27;s redesign in Firefox. Button and icon alignment are generally off by 1-2px everywhere because of it. Guessing they&#x27;re just living with it because Firefox is down in the single-digit percentages of browsershare these days.
评论 #23774077 未加载
评论 #23773825 未加载
SambalOelekalmost 5 years ago
Is there something happening in the font world I don&#x27;t know about? I just spent the past day struggling with fixing my fonts on Arch Linux. I finally just deleted all xorg packages that give bitmap fonts becuase I couldn&#x27;t get any of them to load right in Firefox. This was after a font package totally broke my installation a week ago.
shash7almost 5 years ago
Tangential but I made getsnapfont.com to test how fonts look like on various OS&#x2F;browsers.<p>Unfortunately most designers I&#x27;ve worked with don&#x27;t acknowledge these inconsistencies when designing. For them, their 2x retina mac represents the vast majority of users.
andrewmcwattersalmost 5 years ago
draw_down was downvoted for this, but I agree. If you&#x27;re going to write an article on this, you _should_ know, or at least try to.<p>This would have been more educational if perhaps instead of the author guessing at what behavior should occur, they read the standards[1][2][3] and told us what should occur. There are even definitions in the specifications for how to lookup the nearest available weight.[1][4]<p>It seems like the author doesn&#x27;t understand what liberties you have as an implementor. For instance:<p>&gt; In the computed tab, Edge, Chrome and Firefox are all showing font-weight: bold to be computed to a font-weight of 700, whereas Safari&#x27;s computed font-weight doesn&#x27;t have a numerical value, it just remains computed as &quot;bold.&quot; But this still doesn&#x27;t explain much.<p>Well, OK, but the _author_ didn&#x27;t explain much. This little tidbit isn&#x27;t meaningful, it&#x27;s just an observation without an explanation as to why. But a cursory read shows the specifications clearly state that bold is the same as 700.<p>&gt; Wait.<p>&gt; I add ,700 to the end of this string: Poppins:400,600. My heading re-renders and now matches Safari.<p>Well, yeah.<p>From Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification, &quot;15.6 Font boldness: the &#x27;font-weight&#x27; property&quot;<p>&quot;If the desired weight is less than 400, weights below the desired weight are checked in descending order followed by weights above the desired weight in ascending order until a match is found. If the desired weight is greater than 500, weights above desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found. If the desired weight is 400, 500 is checked first and then the rule for desired weights less than 400 is used. If the desired weight is 500, 400 is checked first and then the rule for desired weights less than 400 is used.&quot;[1]<p>From CSS Fonts Module Level 4, &quot;5.2. Matching font styles&quot;<p>&quot;If the desired weight is inclusively between 400 and 500, weights greater than or equal to the target weight are checked in ascending order until 500 is hit and checked, followed by weights less than the target weight in descending order, followed by weights greater than 500, until a match is found.<p>If the desired weight is less than 400, weights less than or equal to the desired weight are checked in descending order followed by weights above the desired weight in ascending order until a match is found.<p>If the desired weight is greater than 500, weights greater than or equal to the desired weight are checked in ascending order followed by weights below the desired weight in descending order until a match is found.&quot;[4]<p>&gt; So what do I do to render headings consistently across browsers and platforms?<p>Read the specifications. If you&#x27;re arguing that Core Text doesn&#x27;t draw like FreeType or Direct2D&#x2F;DirectWrite, well, sure, but the specifications don&#x27;t force you to output particular bitmaps.<p>[1]: <a href="https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;CSS2&#x2F;fonts.html#propdef-font-weight" rel="nofollow">https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;CSS2&#x2F;fonts.html#propdef-font-weight</a> [2]: <a href="https:&#x2F;&#x2F;drafts.csswg.org&#x2F;css-fonts-3&#x2F;#font-weight-prop" rel="nofollow">https:&#x2F;&#x2F;drafts.csswg.org&#x2F;css-fonts-3&#x2F;#font-weight-prop</a> [3]: <a href="https:&#x2F;&#x2F;drafts.csswg.org&#x2F;css-fonts-4&#x2F;#font-weight-prop" rel="nofollow">https:&#x2F;&#x2F;drafts.csswg.org&#x2F;css-fonts-4&#x2F;#font-weight-prop</a> [4]: <a href="https:&#x2F;&#x2F;drafts.csswg.org&#x2F;css-fonts-4&#x2F;#font-matching-algorithm" rel="nofollow">https:&#x2F;&#x2F;drafts.csswg.org&#x2F;css-fonts-4&#x2F;#font-matching-algorith...</a>
elondaitsalmost 5 years ago
It&#x27;s a webkit thing.<p>Try<p>-webkit-font-smoothing: antialiased<p>and you&#x27;ll get the version with less weight, while &#x27;subpixel-antialiased&#x27; is the heavier one. This weight difference is more noticeable in white text against dark backgrounds.<p>Photoshop offers several options on how to render text that show different &quot;weight&quot; in a similar way... they&#x27;re called &quot;Crisp&quot;, &quot;Strong&quot;, &quot;Smooth&quot;, etc. In particular there&#x27;s a &quot;Mac LCD&quot; one which I think matches this &quot;issue&quot; seen in Safari.
评论 #23773560 未加载
评论 #23774202 未加载
评论 #23773581 未加载
dilandaualmost 5 years ago
In which a novice web struggles aimlessly before giving up?<p>Compelling stuff.
komealmost 5 years ago
Do websites need to look exactly the same in every browser? <a href="http:&#x2F;&#x2F;dowebsitesneedtolookexactlythesameineverybrowser.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;dowebsitesneedtolookexactlythesameineverybrowser.com&#x2F;</a>
jibbersalmost 5 years ago
Could this be related to macOS font smoothing? System Preferences &gt; General &gt; uncheck &quot;Use font smoothing when available&quot;
评论 #23773371 未加载
DiabloD3almost 5 years ago
This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users.<p>Safari enforces the OSX &quot;thick antialiasing&quot;, causing really thick fonts. This also causes really thick fonts, unreasonably so, in normal non-web apps.<p>The reverse, unfortunately, is true: a lot of web developers worship at the altar of Apple, and have screwed up perfectly good websites by making their fonts too thin: on <i>every other OS, with every other browser</i> thin fonts <i>break</i>.<p>If you are a web developer, for the love of all that is holy, test your website on a normal Windows machine, with a normal 100% DPI conventional monitor, in both Chrome and Firefox. If it misrenders, this is on <i>you</i>, and you will look positively incompetent to the 95% of users visiting your website.<p>Apple users are a vocal minority, they do not represent the silent majority who will easily click away from your website because its unreadable.<p>The fix on OSX, if you&#x27;re still willing to use that, is `defaults -currentHost write -globalDomain AppleFontSmoothing -int 1`, and if you have a non-Retina display, combined with `defaults write -g CGFontRenderingFontSmoothingDisabled -bool NO` to turn sub-pixel font rendering back on.<p>Defaults are 2 and YES, respectively. AppleFontSmoothing accepts values 0 through 3. 0 is off, 1 is light, 2 is medium, 3 is french roast columbian bold.
评论 #23774263 未加载
评论 #23775039 未加载
评论 #23773615 未加载
评论 #23773652 未加载
评论 #23778288 未加载