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;
}
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 to correct some text size. If you fx look at this page: the headlines are going out from the page on a mobile device, (or in the 'blisk' browser) so you have to scroll right to see the text.
The site has a lot of pages, and I cannot find the CSS or Sass file that is controlling the font.
Does anybody knows if I can see in the browser which document the <h2> tag is using. As I see it I cannot see it through the developer tools?
You have just one minified css
<link href="/bundles/css?v=SJ37P6CfqPJUAiVuLtUYrkvpJkXmJUlOWclWB_n1UKw1" rel="stylesheet"/>
The problem is here:
.h2, h2 {
font-size: 40px;
padding-top: 30px;
}
Since you have long words the browser try not to broke the words into multiple lines. You can decrease the font size for a certain breakpoint:
#media screen and (max-width: 640px){
.h2, h2 {
font-size: 26px;
}
}
As Alessio mentioned the error lies in the h2 part.
If you switch over to developer tools you can see the width of certain html elements (some kind of overlay). In this case the h2 element goes over the border, which results in that scrolling problem. Your text or specifically this word "Søgemaskineoptimering" is too long and too big to fit in one line (mobile view). You can either change the font-size or set a wordbreak . Alessio already explained the breakpoint approach.
Best regards,
KN
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.
I'm working on a project where the height of the content container is limited, and on a few select browsers (mostly Chrome on Android) the text seems to be breaking in different places, even though almost all font properties seem identical, so far I've checked:
Width of the container element
font-size
line-height
font-family
letter-spacing
All of which are identical, both in their given and computed values.
This wouldn't usually be a massive problem, but because of the content container height constraint, these discrepancies are causing me a massive headache.
I've managed to replicate the problem in a fiddle with the following code:
HTML
<p>We are not able to sleep or We cannot sleep.</p>
CSS
p {
font-family: "Times New Roman", serif;
font-size: 11px;
font-style: italic;
letter-spacing: 0;
max-width: 200px;
}
The text in this example renders on one line in the majority of browsers, however in some the last word "sleep." appears on a new line.
You can see screenshots of this example in a number of different browsers at:
http://www.browserstack.com/screenshots/cf75bb4fa9a22db2e660a0073698be86b55becb6
Is there something I'm missing here? Is there any way to ensure the text will render in the same way accross a number of devices and browers?
The details of font rendering vary by browser and platform, and they cannot be controlled in CSS. Besides, different computers may have (slightly) different fonts under the same name, or e.g. lack Times New Roman entirely (most smartphones lack it, for example).
As a workaround, if specific line division is crucial, consider writing the text as preformatted (i.e. dividing it into lines in HTML source the way it should appear in display) and using white-space: pre. The drawback is that some lines might hit or even cross the right edge of the area reserved for the element. But if you do not set a background or border, this will be barely noticeable.
I'm afraid that the only solution here is using an image using width="XXX" or tell the client that is completely impossible to make a web identically on every browsers unless you use disgraceful methods just like using an image instead of text.
I was able to solve the problem in my browser by replacing the max-width with min-width see this http://jsfiddle.net/79j57L8L/4/
p {
font-family:"Times New Roman", serif;
font-size: 11px;
font-style: italic;
min-width: 200px;
}
Must be something basic I'm missing here. I thought that font-weight:bold should not change how much vertical space the text takes. Especially when the line-height is set to be higher than the font-size.
http://jsfiddle.net/Arkkimaagi/7xAyy/
On my OSX chrome those three text heights do not match. The second one with font-weight:bold is 1px higher than the rest. The third div is just an example of fixing the problem (poorly)
I'm trying to set the line-height to something specific (18px) here, to have "vertical rhythm"
My question is, how can I have bold and normal text both with same line-height as in the example?
[edit:]
here's what I see on my mac
Also, here is what I ment by "vertical rhythm": http://www.alistapart.com/articles/settingtypeontheweb
- the baseline grid is more visible in the example: http://www.alistapart.com/d/settingtypeontheweb/example_grid.html
Sometimes adding top vertical align will solve this (depending on font size/family).
strong { vertical-align: top; }
In your fiddle example, because you have set a line height on the container (div), you can simply add the following:
span { line-height: 1em; }
It completely depends on the fonts you are using. Nothing about OSX or Chrome text rendering would ensure that two different fonts (and Helvetica-neue and Helvetica-neue-bold are two different fonts) would have the same vertical space even at the same font-size and line height.
Even though that is too much to ask you might think that two different fonts from the same family might be consistent, and usually they are, but sadly the two fonts you have chosen are not.
Setting an absolute line-height on both the container and the bold text, or giving bold text a line height of 1em (as DaveC says above) both fix this, e.g. from the jsfiddle you just need to add line-height: 1em
.bolded span {
font-weight:bold;
line-height: 1em;
}
Or why not follow HTML standards and use the correct tags instead of bolded spans? E.g.
strong, em { line-height: 1em }
I've encountered very similar problem with Chivo font: http://www.fontsquirrel.com/fonts/chivo. Right now I'm using the ugliest hack (works on current Firefox and Chrome, IE untested yet):
strong { vertical-align: top; position: relative; top: -1px; }
I try not give up on Chivo quite hard as you see ...
I think this is a font issue. I found differing line heights for the italic variant of Nunito (Google Web Font). When I switched to a reworked version of that font called "Nunito Sans" the issue was resolved.