I have a text element with the follow CSS rules:
box-sizing:border-box;
color:rgb(38, 38, 38);
display:block;
float:left;
font-family:Brandon, sans-serif;
font-size:14px;
font-weight:700;
height:20px;
line-height:16.8px;
list-style-image:none;
list-style-position:outside;
list-style-type:none;
position:relative;
text-align:left;
text-size-adjust:100%;
visibility:visible;
-webkit-tap-highlight-color:rgba(0, 0, 0, 0);
My question/problem is that while the rendered element width is pretty constant across browsers (between 146.50px and 150px) on Safari it's up to 165px almost 10% extra compared to all other browsers. Since I have a few elements in a row this difference makes the whole design not fit on Safari...
I have tried all kind of tricks like:
- letter-spacing, word-spacing
Everything suggested here: Safari font rendering issues
But I cannot find any solution. I have tested the design in:
- Firefox (Windows and Mac), Internet Explorer, Edge, Chrome (Both windows and mac) and the result is more or less constant. Chrome Mac vs Windows have a difference of about 1 pixel.
What is the reason that Safari makes the item so much wider and better yet is there a way to normalize this across browsers (without setting a fixed width of course)
Edit
#font-face {
font-family: "Brandon";
font-style: normal;
font-weight: normal;
src: url("../fonts/Brandon_reg.otf") format("opentype");
}
Two possibilities at first glance:
The otf format is not supported by Safari
There's no bold or 700 version of font Brandon provided, browsers try to mimic the bold version, which may vary in the rendering result. You may try to disable it by adding font-synthesis: none to text or providing the bold version of your font.
Related
font-variant: small-caps;
font-size: 12px;
Firefox:
Capital letters: 12px
Lowercase letters: 10px
Chrome:
Capital letters: 12px
Lowercase letters: 8px
How to harmonize that without using JavaScript?
Webkit browsers display small-caps smaller than other browsers so.. You can use CSS media queries to easily sniff out webkit browsers like Chrome and Safari. Try something like this:
#media screen and (-webkit-min-device-pixel-ratio:0) {
.some-element-using-small-caps {
font-size: .85em
}
}
You can target the browsers individually by using css hacks like this:
#-moz-document url-prefix() {
//firefox specific css here
}
#media screen and (-webkit-min-device-pixel-ratio:0) {
//chrome specific css here - this will also hit other webkit browsers like safari tho
}
A nicer way however in my opinion involves a tiny bit of javascript that detects the browser and sets a class on the html element and then you can use that class as a base for targeting the individual browsers.
in the end it would look something like this:
<html class="firefox">
...
</html>
.firefox .rulename {
//firefox specific css here
}
and of course the same for chrome and whatever else browser
I am having a similar issue with a much weirder issue between Safari on iPad vs Safari on Desktops, showing a different scale for small-caps at 16px. For some reason small-caps is a bigger size on iPads, kinda matching that of Firefox.
Adjusting the font size or letter-spacing a half pixel less or so, can mitigate the issue without further additional hack. By essentially finding a tiny middle adjustment which trigger on one browser but not on another, to try and get as close as possible.
What I have observed for Firefox and IE, is that fonts tend to scale with many more intermediate sizes than that of Webkit. For example, in IE and Firefox, 15.6px is a tiny bit bigger or use more tracking to adjust, than that of 15.5px, and so is 15.7px, 15.8px etc. With a difference for nearly every 0.1 pixel. Whereas in Safari the difference is only perceived for every 0.4px or so.
For my small-caps case here which created an overflow issue, I used 15.5px, which is barely different from 16px on Safari (Desktop), yet bring down the small-caps size for IE and Firefox as close as possible to Safari's.
I have a page with an emoji followed by a space and some text. For example, "👥 Friends" (character is "busts in silhouette", U+1F465). In Safari and Firefox on macOS, it renders with a space between the emoji and the following text as expected.
In Chrome, however, the space appears as if it's absent:
If I remove the space, Chrome renders the text overlapping with the emoji. It seems like the width of emojis as rendered in Chrome is less than the actual character width.
Is there any way I can get the desired appearance (a normal-width space) cross browser without resorting to an image or icon font? I've tried messing with some CSS properties like text-rendering without success.
<style>
.friends {
font-family: Helvetica, Arial, sans-serif;
}
</style>
<span class="friends">👥 Friends</span>
JSFiddle
I had the same issue, and found out that it happened on non-retina screens only.
To fix it, we applied a margin through a media-query like this:
<span class="friends"><span class="emoji">👥</span> Friends</span>
<style>
#media
not screen and (min-device-pixel-ratio: 2),
not screen and (min-resolution: 192dpi) {
span.emoji {
margin-right: 5px;
}
}
</style>
This is a pretty minimal media-query. You should probably use a more complete one like https://stackoverflow.com/a/31578187/1907212.
This is a Chrome bug (See detail here)
This is related to displaying emojis in Mac Chrome on a non-retina screen. My monitor had a non-retina screen (where the spacing / cursor position were info), but were absolutely fine on my Mac.
It's February, 2020, and this issue still very much exists (link to open Chrome bug). Chrome 88.0.4324.150 on MacOS X 10.15.7 on a 2019 16" MacBook Pro: dragging a browser window between the internal Retina monitor and an external ultrawide monitor changes the rendering of the emoji.
As an alternative to Julien's answer, instead of selectively specifying a margin-right to correct an imbalance, we can "force" the width of the actual emoji character(s) to be equal in a cross-browser way using letter-spacing.
In essence, our issue is that most characters with the Roman alphabet don't have a height-to-width ratio of 1:1, but most emojis (roughly) do have a height-to-width ratio of 1:1. This is one way of describing what we're seeing with the spacing between emojis and ANSI characters.
See example screenshot here
letter-spacing sets the horizontal spacing behavior between text characters. When paired with CSS em units, we can use this property to "force" each character/emoji to render in a roughly 1:1 box. This might need to be adjusted depending on the font or character set you use.
According to the sources below, a Roman character is often roughly 0.5 as wide as it is tall, so we can simply do:
span.emoji {
letter-spacing: 0.5em;
}
<span class="friends"><span class="emoji">👥</span> Friends</span>
<style>
span.emoji {
letter-spacing: 0.5em;
}
</style>
This method means that in browsers that render emojis correctly, we aren't adding an extra margin-right.
https://graphicdesign.stackexchange.com/a/114955
https://web.archive.org/web/20210118205344/https://www.lifewire.com/aspect-ratio-table-common-fonts-3467385
What I would do is add another span within the .friends span that contains the emoji, have it use a right margin, and not have a space after it:
.friends {
font-family: Helvetica, Arial, sans-serif;
}
.friends span {
margin-right: 10px;
}
<span class="friends"><span>👥</span>Friends</span>
That way you don't have to worry about space rendering ;)
Hope this helps! :)
Removing BlinkMacSystemFont from font-family fixed issue for me, you need to close and reopen tab to see effect.
As of (at latest) Chrome 79, this issue no longer exists.
This problem still exists on Chrome 83 on MacOS 🤨
I think I found the solution
[data-emoji] {
font-style: normal;
font-weight: normal;
}
[data-emoji]:before {
content: attr(data-emoji);
margin-right: .125em;
}
I am having a weird issue in Chrome where a Google Font is showing inconsistent letter heights. It only happens when I use text-transform: uppercase and it is fixed if I use font-weight:bold. I have some example code, where you can see the S is too tall in the word TESTING:
body {
font-family: 'Exo 2' !important;
line-height:1.42857143;
}
div {
width:40px;
}
span.upper {
display:block;
margin-top:20px;
font-size:18px;
text-transform:uppercase;
}
span {text-transform:uppercase; }
<link href="//fonts.googleapis.com/css?family=Exo+2:200,300,400,700,300italic,400italic,700italic|Raleway:200,300,400,600" rel="stylesheet" type="text/css">
<div>
Broken:<br>
<a href="#">
<span class="upper">Testing 123</span> </a>
<br>Normal:<br><br>
<span>Testing 123</span>
</div>
If I change the font to arial, it's fixed. Is there some CSS property I need to reset so that the font will render correctly?
This is a well known bug in Chrome on Windows. Chrome has made the political/ecosystem move to reduce dependencies on other companies and other established tech, like the move to fork Blink from Web-Kit. Chrome has also decided to ditch Microsoft font rendering. The result is poor sub-pixel rendering. You've noticed that once you bump your font up in size or weight the issue is resolved because the character strokes are wider than one pixel.
One solution for you: you can go into Chrome's flags:// to enable Direct Write.
But that doesn't help your users, of course. There are a few hacks.
One hack is to change up your font stack, so that SVG is called specifically for web-kit.
You can do this with a media query hack:
#media screen and (-webkit-min-device-pixel-ratio:0) {
#font-face {
font-family: 'chunk-webfont';
src: url('webfont.svg') format('svg');
}
}
So there are issues with this. It's not future-proof. It's a hack. But it works for now, and Chrome will be fixing this in the near future. Other, hacks include calling SVG first in your stack, but it has less reliable results.
I was having the same issues with Windows browsers and I tried using SVG first in the stack but it didn't work - I later found out that Chrome has since ditched support for SVG fonts. So I tried using a TTF version of my font placed first in the stack and for some reason it resolved the issue. Tested it in Chrome, Firefox and Edge. Oddly if I reference the TTF in a data URI it goes back to inconsistent letter heights again.
In opera, chrome, safari, firefox my website letters are as supposed to be, sometimes bold when I asked them to and sometimes normal. However, in IE 9,8,7 they are always bold no matter what. Even when I say font-weight:normal; or font-style:normal; they stay bold :|
Anyone had this problem and knows how to solve it?
For example I have p:
HTML
<p id="copyright">© 2013. Company Name. All rights reserved.</p>
CSS
#copyright {
float:right;
margin-right:5px;
margin-top:42px;
color:#7d7d7d;
font-family:Helvetica;
font-style:normal;
}
Thanks.
That's because of Microsoft's ClearType
Sadly, many fonts looks nearly the same when switching from "normal" to "bold" :(
You should try with a different font (verdana has for example a stronger difference between normal and bold)
Also, you could try to use a .svg web font, which will not be affected by cleartype
HTH
Helvetica isn't a standard font on Windows. Try changing:
font-family:Helvetica;
to
font-family:Helvetica, Arial, sans-serif;
If that's no good, try flipping the order of Arial and Helvetica – it may be that your Windows box has a bad copy of Helvetica installed, and that the ClearType settings in those browsers are making it look wider than it should be.
I am using "Populaire" font. I am having a weird problem.
When I view the font in laptop, fonts are clearly formed without any distortion (on all browsers) but when the same was seen on other systems(not all but few systems do), it started appearing distorted (again, on all browsers). I am not sure what will cause the font to be distorted in some systems. Please advice. Here is the CSS that I have used in my code..
#font-face {
font-family: 'Populaire';
src: url('font/populaire.eot');
src: url('font/populaire.eot?#iefix') format('embedded-opentype'),
url('font/populaire.woff') format('woff'),
url('font/populaire.ttf') format('truetype'),
url('font/![enter image description here][2]populaire.svg#populaire') format('svg');
}
h1 {
font-family: 'Populaire','Helvetica neue',Helvetica,Arial,sans-serif;
font-size: 2em;
font-weight:lighter;
color: #ffffff;
background-color: #8D407C;
width:250px;
margin: 0;
padding: 0;
}
The type in your second screenshot is being displayed without anti-aliasing. This might occur because the second computer does not have Cleartype enabled.
http://www.microsoft.com/typography/cleartype/tuner/step1.aspx
In Windows Vista, Windows 7, and OSX Cleartype (or an equivalent anti-aliasing engine) is enabled by default.
Without anti-aliasing, any typeface that has not been specifically hinted for on-screen display will appear 'jaggy', since its curves do not neatly fit to the screen's pixel grid.