From the images below, you can see that the font rendering used by safari adds some white lines to some characters. This occurs in Safari for both iOS and Mac. While in the example below it is not as noticeable, in practice it can be quite distracting.
I noticed this happened after I added font-weight: 400; to my text. The reason I added it was to fix another issue by Safari which rendered by font with large kerning between letters see this Stack Overlow question.
This is the entire CSS for the text:
h2 {
font-family: 'My-Font', sans-serif;
font-size: 3.5em;
line-height: 1.2em;
margin-bottom: 0.5em;
text-align: center;
}
Is this another bug in Safari and is there a workaround if so? Thanks.
Some folks recommend
text-rendering: optimizeLegibility;
Other
transform: perspective(1px);
Hope it helps.
Related
I have a simple <a class="button"> element, and I noticed on Firefox, the text wasn't as vertically aligned as on Chrome.
Here is some sample code:
Here is my CSS:
body {
font-family: sans-serif;
}
.button {
font-size: 3em;
display: inline-block;
padding: 0.6em 1em;
text-align: center;
text-decoration: none;
text-transform: uppercase;
color: #333;
background-color: #7d8cdd;
}
.button > span {
background-color: #8cd5ed;
}
<span>CLICK ME</span>
Now what I'm not sure, is why Firefox is rendering the text so poorly. That is, it is putting a lot of space beneath the text, but not a lot above it.
Here are some screenshots:
Firefox:
Chrome:
Searching around, I wasn't able to find much reading material on the subject.
Anyone have any ideas why Firefox renders text with space at the bottom, but not at the top? Thanks.
NOTE: I am running Mac OS X Yosemite (10.10.5).
Figured it out. When putting font-family: sans-serif;, Chrome will choose Helvetica Neue, whereas Firefox will choose plain Helvetica. That difference of space is in the font files themselves.
Explicitly declaring
body {
font-family: "Helvetica Neue", sans-serif;
}
instead "fixes" the issue on Firefox, aka, makes it so FF and Chrome will use Helvetica Neue as the render font (assuming it is available).
I ask this because when I try to create a CSS font stack for multi-language content, such as English and Chinese, the final rendering is affected by the first font in the stack (usually Latin ones, since most Chinese font comes with Latin support).
See this Codepen, for example.
div.a p {
overflow: hidden;
}
p {
background-color: red;
border: 1px solid black;
display: inline-block;
}
.chinese-only {
font-family: "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.english-chinese {
font-family: "Avenir Next", "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.chinese-english {
font-family: "Hiragino Sans GB", "Avenir Next", sans-serif;
font-size: 24px;
line-height: 48px;
}
What I am seeing:
Since Chinese glyphs only appear in the Hiragino Sans GB, I expect all Chinese blocks to use the same line height. But they are apparently affected by adding the Avenir Next font at the top of the stack.
Since both Firefox and Chrome on OSX renders my example the same, I wonder if the CSS specification mentions anything about this. CSS 2.1 fonts spec doesn't appear to state what to do with line height when you fallback on missing glyphs.
Updated: Safari does render differently, but unfortunately the difference is due to overflow: hidden, not glyph fallback. My updated example may show this a bit clearer.
On Chrome and Firefox
On Safari
And if you are really into font-related headaches, try this example showing different font stacks, and see how they differ on each browser.
This is pretty much going to come down to the user agents. Any time the CSS specification says, “not defined by this specification”, that’s code for “we’ll let browsers do whatever they think is best and then try to get them all to behave consistently after a few years of doing it differently”.
Furthermore, the latest CSS Inline Layout Module states right at the top of Section 1 (Line Heights and Baseline Alignment):
This section is being rewritten. Refer to section 10.8 of [CSS21] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.)
That’s from last month. So, you know, good luck and Godspeed, basically.
Interestingly, I see a different result in Safari 6.2.2 than you posted:
If there’s a difference between that and the latest Safari, you might be able to track down a bugfix between the two versions that explains why it changed.
I have a problem with fonts, because they don't render same on Windows and on OS X. On Windows, characters are vertically aligned in line, but on OS X, the characters are positioned much closer to top of the line.
I highlighted the text in screenshots so you can see the difference.
I am using font Gotham. Any ideas? Do I have to use browser-specific hacks or is it a font issue?
Link to JSFiddle: http://jsfiddle.net/wewo/myh4amud/
body {
font-family: 'Gotham', Arial, sans-serif;
background-color: #282828;
font-size: 14px;
font-weight: normal;
}
div {
color: white;
font-size: 5em;
padding-top: 15px;
padding-bottom: 6px;
line-height: 1em;
}
<div>3</div>
Thank you!
The problem is in process converting or generating webfont font.
I use tool Font Squirrel for convert correct, with this option EXPERT... :
If don't work with Google Font, download him and send for convert.
Problem with Win Ascent and HHead Ascent fields in font. Windows use Win,
mac - HHead. Use FontForge for edit this.
This problem exists ONLY on Mac Safari.
Other browsers / other OS works properly.
The problem:
Observe the font weight of the top navigation here: http://www.octa.com (WordPress)
Then observe the font weight of the top navigation here: http://www.octa.com/products (Magento)
Note that while they are served by different code (WP vs Magento), the css is nearly identical between the two pages.
Here's the relevant bits of the css:
nav.menu li a {
font-family: 'VegurLight','Myriad Pro',Arial,Helvetica,Sans-Serif;
font-size: 20px;
text-align: left;
}
nav.menu li a, #subnavwrapper nav li a {
color: #FFFFFF;
font-weight: normal;
height: 50px;
line-height: 50px;
padding: 0 46px 0 0;
}
nav li a {
display: block;
line-height: 1em;
text-decoration: none;
}
body {
color: #000000;
font-family: "Lucida Grande","Lucida Sans Unicode",Helvetica,Arial,Verdana,sans- serif;
font-size: 14px;
line-height: 1.55em;
text-align: center;
background: black;
}
Note that the font is imported using #font-face.
I've tried everything - many answers here on SO and other articles. Note that none of the below styles gleaned from other answers / resources corrected the font display.
font-variant:normal;
-webkit-font-smoothing: antialiased;
text-shadow: rgba(0, 0, 0, .01) 0 0 1px;
Try -webkit-font-smoothing: antialiased;
I've found that this simple change made Safari's font-weight property much more reliable.
(I cannot post comments so I can only add my findings to the conversation by posting.)
I have found that text in fixed position elements appears lighter weight than other types of positioning in Safari. Therefore could not be ignored as suggested in other places.
Adding --webkit-font-smoothing: antialiased does solve this , but then it looks lighter than in Firefox. Which can be fixed with -moz-osx-font-smoothing: grayscale
fiddle here to show the problem - Safari only
With the comments / prodding from #JukkaK.Korpela, I discovered a few things:
First, the root of the problem is this:
-webkit-backface-visibility: hidden;
Which was added to the code to solve an animation problem per this answer: iPhone WebKit CSS animations cause flicker
Don't know how to solve the font and solve the flicker, but I can at least choose which one to solve now.
Second, as an avid Firefox/Firebug user, I had tried using Firebug Lite in Safari, as well as another extension for Safari, and they did not work. So, for all of you out there who may be trying to troubleshoot Safari-only issues, here's a big tip:
Safari's "Develop" tool. Didn't know about it at all until I did some searching today, but it's a menu item in the toolbar. If you don't see it, then go to Preferences->Advanced, and check the "Show Develop Menu in Toolbar"
With that tool, I was able to troubleshoot and solve this quickly.
I have a simple style for a 'dropcap' type design for p tags in my CSS.
p.introduction:first-letter {
float: left;
font-family: 'Times New Roman' , Times, serif;
font-size: 300%;
line-height: 1em;
margin-right: 0.08em;
margin-bottom: -0.25em;
}
This seems to be working fine across all browsers, however I am getting peculiar behavior in Firefox. The letter drops down into the text below it.
Normally, I would debug it in Firebug, but here's the strange part - It doesn't show up in Firebug! I really have no clue what is causing it. I have reproduced it in the following jsFiddle.
http://jsfiddle.net/4zMex/
My standard browser is Chrome. This works in Safari and IE9 as well. Only Firefox exhibits the strange behavior.
Removing your negative margin-bottom solves the problem. Why is this needed?