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;
}
Related
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've found an inconsistency among browsers in handling font-size (on Mac OS X 10.11.4). I'd like to know if this is a bug in Firefox, or a bug in CSS, or am I not understanding something about CSS?
This JSFiddle shows the details. In a section like this:
<pre>Start of pre section
<code>**problem here!**</code>
End of pre section
</pre>
the style code { font-family: Courier; } changes the font-size shown by Safari and Chrome, but not in Firefox. Yet in other sections, the code element size increases from 13px to 16px in all the browsers.
Why does the font-size increase from 13px to 16px after setting the font-family in all browsers?
Perhaps Firefox is changing the font-family but not the font-size. Yet it does change the font-size in other places, like in code inside a p element or inside a list.
I'm guessing the solution is to just aggressively set explicit font size with pixel units wherever I care about it (ignoring accessibility).
Quote from possibly related Firefox bug from 2006: Bug 328621 - strange default monospace font size -- differs from the proportional fonts
Though the inter-browser portability problem this imposes doesn't seem that trivial to me. The last time I wanted to markup HTML so that the monospaced parts showed the same in both Mozilla and M$IE I had to resort to absolute font sizes, which should be certainly avoided due to the accessibility problems they impose.
And yes, there's a simple workaround -- changing the settings. But most of the users will use defaults. :-(
This issue is not new; it has been known for many years that browser handling of monospace fonts is incredibly screwy and inconsistent across browsers. A number of workarounds are available that don't require you to override the monospace font preference set by the user, the most perplexing of which is to specify
font-family: monospace, monospace;
That's right: two monospace keywords at the end of the font stack. Nobody knows why this works; it just does.
For what it is worth, Firefox's UA stylesheet contains references to a -moz-fixed keyword which refers to the preference that is set by the user, which includes both the family and the size despite it being a value for the font-family property. Firefox ships with the preference set to 13px in whichever the system's default monospace font is. It would seem that monospace, monospace forces the browser to compute the element's font-size according to the spec while still preserving the preferred monospace family, at least. But this is just a guess.
Is this a bug? It depends on whom you ask. If you ask browser vendors, they'll probably say this is intentional. If you ask other authors, they'll probably also call it a bug. Is this a spec violation? No, because the spec allows browsers to implement defaults however they like.
Why does the font-size increase from 13px to 16px after setting the
font-family in all browsers?
probably because the browser's default stylesheet has these settings.
I'm guessing the solution is to not try to understand all this but
just aggressively set font and font-size wherever I care about it.
Not sure what you mean by "agressivly" but yes: If you have particular demand for that style, set it as precisely as possible in your own stylesheet, including font familiy, weight, size etc.
Since I asked the question and got a couple of good faith answers that are however not really answering my question: I'm going to try to prove that this really is a problem with current browsers. See my comment at the end about why this might or might not matter.
Here then are
3 problems with font-size in CSS/HTML in FireFox, Chrome and Safari on Mac OS X 10.11.4:
Problem 1. Changing font-family should not change font-size, but it sometimes does.
I don't know what the "user agent stylesheet" is. There can be all kinds of settings on it. But regardless of those settings, changing font-family should not change computed font-size. (Some fonts might appear larger at the same font size compared to other fonts at same font size, so visually they can look bigger or smaller, but the computed font size number should not change).
notation: in the following
pre(code) means roughly <pre><code>text here</code></pre>
p(code) means roughly <p><code>text here</code></p>
In the default situation, a page with no styles, I see this in all 3 browsers:
pre=13px
pre(code)=13px
p=16px
p(code)=13px
<pre>pre <code>pre(code)</code></pre>
<p>paragraph <code>p(code)</code></p>
Perhaps the user agent stylesheet is something like this:
pre { font-size: 13px }
code { font-size: 13px }
p { font-size: 16px }
The user agent can't be using relative sizes for code, because it appears as 13px inside of both pre and p elements. So it could be this:
pre { font-size: 81.25% }
code { font-size: 13px }
p { font-size: 100% }
or the equivalent using em instead of percentage. Or perhaps a descendent rule with percentages or em:
pre { font-size: 81.25% }
pre code { font-size: 100% }
p { font-size: 100% }
p code { font-size: 81.25% }
But then how do we explain this:
After setting code { font-family: Courier } (or any font family other than monospace) we get:
pre=13px
pre(code)=16px for Chrome & Safari pre(code)=13px for FireFox
p=16px
p(code)=16px
code { font-family: "Courier"; }
<pre>pre <code>pre(code)</code></pre>
<p>paragraph <code>p(code)</code></p>
No matter what the stylesheet is, the font-size should not change after only changing the font-family.
Problem 2. Relative font-size should be based on parent element's computed font-size. But it sometimes is not.
With no styles we have:
p=16px
p(code)=13px
After setting code { font-size: 100%; } we should have
p=16px
p(code)=16px
Instead we still have:
p=16px
p(code)=13px
This is wrong because author style should override default user-agent (browser) style. And relative (percentage) font-size is based on the parent element's computed font-size.
code { font-size: 100%; }
<p>paragraph <code>p(code)</code></p>
Similarly, after setting code { font-size: 120%; } we should have
p=16px
p(code)=19.2px = 16px * 1.2
Instead we have:
p=16px
p(code)=15.6px = 13px * 1.2
code { font-size: 120%; }
<p>paragraph <code>p(code)</code></p>
This shows that parent element is being ignored, and that some phantom value of 13px is being used to calculate the relative font-size.
Problem 3. The standard advice to use html { font-size: 62.5% } and then use em or rem for font-sizing does not work correctly
(Note: FireFox with rem does seem to be correct)
(Note: using the also recommended body { font-size: 62.5% } seemed to produce some crazy results, like doubling of font sizes, so I'm not considering that here.)
With html { font-size: 62.5%; } and code { font-size: 1.6em; } we have:
p=10px
FireFox: p(code)=13.0167px
Chrome: p(code)=13px
Safari: p(code)=13px
These should all be 16px = 1.6 * 10px
body { font-size: 62.5%; }
code { font-size: 1.6em; }
<p>paragraph <code>p(code)</code></p>
With html { font-size: 62.5%; } and code { font-size: 1.6rem; } we have:
p=10px
FireFox: p(code)=16px
Chrome: p(code)=13px
Safari: p(code)=13px
FireFox is the only browser to get it right here.
html { font-size: 62.5%; }
code { font-size: 1.6rem; }
<p>paragraph <code>p(code)</code></p>
I suspect this all doesn't matter much because people are used to slapping font-size styles all over the place in their CSS.
From my reading, there has been an attempt to make web pages more responsive to the native settings on each device: to adapt to varying hardware with more or fewer pixels per inch (PPI); to allow users with reduced vision to request larger text so they can read more easily; etc.
There are various recommendations and a bit of controversy about how to best do this: specify font-size with html { font-size: 62.5% } and use em or rem everywhere seems to be a popular opinion. Lately just using good old px to specify font-size is coming back in style, with the idea that px does not specify actual screen pixels but rather an idealized 96 dpi for the viewer (which may translate to a different number of pixels) and letting the browser's zoom controls handle user desired changes in font-size.
In summary, I think these problems with font size argue against the logic behind most of the advice about "responsive design" for font size. My guess is that this is an area where there is a lot of history factored into how browsers work, and it's near impossible to change now. And of course there are millions of websites with existing code that are all presumably happy with how font sizing is working now.
It seems to me that the only way to get consistent font sizing is to use pixels: px. For example, px at the Root, rem for Components, em for Text Elements. Or just just use pixels everywhere.
Mozilla writes the following about accessibility and font-size
Defining font sizes in pixel is not accessible, because the user cannot change the font size from the browser. (For example, users with limited vision may wish to set the font size much larger than the size chosen by a web designer.) Therefore, avoid using pixels for font sizes if you wish to create an inclusive design.
But with all these bugs with inherited and relative font size it doesn't seem like an option to avoid using pixels. Plus the argument about a reference pixel and using the browser's zoom control seems to solve the accessibility issue.
That's because back in the dark ages one Netscape dev decided to force his personal preferences on everyone else in the browser settings (most coders are young people who think it is smart to destroy their eyes by setting text size one or two sizes smaller than everyone else, they think "monospace" belong to them and "sans serif" to normal human beings).
Thus, Firefox ships with defaults that alias "monospace" to a smaller font size than "sans serif". Pretty much destroys coordinated font sets (where the monospace font is designed to look the same as the serif or sans serif one).
You can "fix" it locally by launching about:config and changing all font.size.fixed.* properties to the same value as font.size.variable.* ones. But since you can't fix all Firefoxes in the wild, that makes the monospace css alias useless for this browser.
Response from OP moved from question to answer:
The answer from BoltClock was super helpful. The page he/she referenced about Fixed Monospace Sizing by Eric Meyer has a thorough analysis and some solutions. It explains some of the browser mechanics related to when the user's font preferences are used, which explains some of the mysterious behavior I was seeing (e.g. why was the code element seeming to inherit a size of 13px when it was the child of a p element with size of 16px: the reason is it actually inherits size medium which causes the browser to use the default browser/user preferences).
For my situation I'm finding I can remove the html { font-size: 16px; } style and instead add the following:
pre { font-family: monospace, monospace; }
code { font-family: monospace, monospace; font-size: 100%; }
This gives me consistent relative font-sizing but still allows the user to set the default font-size. Eric Meyer recommends using monospace, serif but I'm finding that monospace, monospace works, and I think it makes a little more sense when you see it in a style-sheet (it's odd, but looks probably intentional, and it means you really, really want monospace).
I think that the ultimate problem is that the browsers have different font-size defaults/preferences for monospace font, than for other fonts. The main idea of "accessible responsive design" in regards to font-size is to let the user have control over font-size. But when we have several settings for font size (serif, sans-serif, monospace) then that's too many options for the user to set. The user just wants bigger text that they can read. But for the author: they just want the relative sizes of the fonts to be correct at whatever given size.
In case it's helpful to someone else, here are some examples (in the slick Eric Meyer style) showing that monospace, monospace fixes some of the problems I wrote about in my own answer below.
code:before {
content: attr(style);
border-bottom: 1px solid #AAA;
color: #575; margin-right: 0.5em;
}
p {
margin-bottom: 2em;
}
<p>This is a 'p' element with a <code>'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace, monospace">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-size: 100%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace; font-size: 100%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace, monospace; font-size: 100%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace; font-size: 120%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace, monospace; font-size: 120%">'code' element</code> contained within.</p>
I came across a similar issue where I used monospace and the sizes were different in Google Chrome and Edge & Mozilla Firefox. This is because different browsers have different font weights and sizes for standard fonts.
To resolve this issue I used Google fonts and then the fonts sizes were the same in all browsers.
It's been a while (2 years?) since I've done a bigger website. I'm now developing one and as usual, I ran onto some cross-browser difficulties.
The problem I'm solving now can be seen on the picture below - I have a page with a h2 element, which displays differently in Chrome and IE 11. The element has all the properties like line-height, font-size, padding, margin and so fort specified, but still displays differently. In one browser, the text is right on the top of the element, in the other one, it is in the middle. This causes some graphical issues and I can't seem to find a way to resolve this without writing a browser-specific css definition for each browser (Firefox does something similar to and is somewhere in the middle of these two - the text is in the upper part of the element, but not on the very top of it).
The other similar elements like h1 are affected as well.
I understand this is likely related to the way these browsers handle fonts and calculate their positioning, but at the moment, this doesn't help me much. I'd be grateful for any advice you might have, since I'm probably not the first one to be solving this.
EDIT:
I won't insert the HTML code here since this affects all these elements regardless of where they appear. For an instance, the text highlighted in the page is a normal h2 with the following CSS attributes:
color: rgb(0, 0, 0);
display: block;
font-family: 'Myriad Pro', Arial;
font-size: 22px;
font-weight: bold;
height: 27px;
margin-bottom: 0px;
margin-top: 20px;
text-transform: none;
width: 634px;
normal has this css:
font-size: 14px;
margin-top: 10px;
margin-bottom: 12px;
line-height: 17px;
So I've found a solution. Little surprising, but makes sense.
I'm using Typekit from Adobe, which is something like google fonts. I actually found out that the cause of this text-shifting is the fact that I'm using the typekit font. When I switched to Arial, everything was fine.
I also came acrticle which describes the topic: http://blog.typekit.com/2010/09/13/updating-vertical-metrics-for-cross-platform-consistency/
The problem has to do with baseline and em boxes set wrong in the given font I used. Switching to another font which had these properties set correctly fixed my problem.
Thanks for all your help guys.
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.
I have a TEXTAREA where spacing is very important. I formatted it as follows:
TEXTAREA {
font-family: Tahoma, Arial;
font-size: 8pt;
letter-spacing: 0px;
line-height: 13px;
}
How, if I enter some text, the line height is not correctly applied: The last line of every paragraph (before pessing enter or shift-enter) is one pixel to high:
This problem only occurs in Internet Explorer 9, not in Firefox 7 or Chrome 14 (haven't tested older versions so far).
Is there a way to get rid of thad?
BTW: It does not happen for the last line of the textarea, unless there is a linebreak behind it.
Regards,
Steffen
I know this may not actually help entirely nor be the full answer, but it may be worth while reading up a little on the use of !important declaration within CSS.
http://www.impressivewebs.com/everything-you-need-to-know-about-the-important-css-declaration/
The only reason why this springs to mind is there may be another style/declaration that is applied after which is causing some sort of problem and this will make sure your textarea has the correct styles applied to it.
You may also want to check that any <p> CSS declarations are not causing conflicts/problems with any bottom or top margin's/paddings? Same goes with span or any other styles that could potentially cause some sort of problems.
Like I said, I'm aware this may not help in the slightest but it could be a possibility.
I have had similar problems with the last line in a textarea in IE8. When my textarea had a line-height of less than 18px, the cursor changed the line-height. The reason I bring this up is your line-height of 13px is quite small. You may want to experiment with larger line-heights to see if the problem goes away.
I just went many many rounds with this issue and finally discovered that IE9 is adding extra padding to textareas. Line height, height, etc had no effect. This did the trick:
padding: 0px !important;