I noticed that in Chrome and Safari, my Courier text is tiny. In Internet Explorer and Firefox, the Courier text is comparable in size to the rest of my text. Is there something wrong with my CSS?
#article pre,
#article code {
display: block;
font-family: courier, monospace;
background: #f7f7f7;
padding: 0.6em;
-moz-border-radius: 4px;
-webkit-border-radius: 4px;
border: 1px solid #ddd;
margin: 0 0 1em 0;
}
Yeah, WebKit has separate default font size preferences for normal and monospaced fonts. When you use a font size derived from a relative font size (ie none of the text's ancestor elements have an absolute font size), you get different sizes for monospaced and normal fonts.
(This wouldn't necessarily be a bad thing, except that the default preference of much smaller monospaced fonts isn't really sensible and most users won't have changed it.)
I think this has changed over different versions; originally IIRC the different base font size for monospaced fonts was applied to any element whose font-family list had monospace in it. Now this behaviour only seems to happen when the font-family property is set to exactly monospace. Your example of courier, monospace doesn't trigger it for me; weirdly, neither does it happen with monospace, sans-serif, even though then the font will always be monospace and sans-serif will never be used. This behaviour matches Firefox.
You're probably not defining a font-size anywhere, so it's falling back to browser default.
Related
I'm experiencing the following issue in both Safari and Chrome.
body {
font-size: 15px;
line-height: 1.2;
}
body, .same-font {
font-family: Helvetica, sans-serif;
}
code {
font-family: Courier New, sans-serif;
}
<ul>
<li>Without any code - 18px height.</li>
<li>With <code>code</code> - 20px height.</li>
<li>With <code class="same-font">code.same-font</code> - 18px height.</li>
</ul>
Run the above snippet and the inspector. You can notice that the code element doesn't have anything modifying its font-size or line-height except body which it's inheriting from.
It's not adhering to that inherit though, because the height of its containing li is 20px, not 18 like the others... I'm not sure where that height is coming from, because the code element itself has a height of 17px (which is also of unknown origin).
When the normal/body is applied to the code element (like on the third list item), it goes back to 18px like normal. To me this means it's not any other properties that the user agent has imposed on the code element affecting the height - solely the font-family.
EDIT: For reference, something in StackOverflow's styles prevent this behaviour. The following list items all have the same height:
One
two
Three
EDIT 2: Apparently not.. if you change their monospace font to Courier New then the same problem would persist.
How can this change in size be prevented? i.e. How can you specify a line height that will be used even if the fonts within that line continue to change?
An example use case would be in a design with vertical rhythm - each line's height and the total height used by an element should be a multiple of 18px (i.e., if using that grid size) - a 20px line throws off the rhythm.
I ended up solving my own problem (to an acceptable extent) by simply tweaking with the font family and size until it worked for me:
body {
font-size: 15px;
line-height: 1.2;
}
body, .same-font {
font-family: Helvetica, sans-serif;
}
code {
font-family: Menlo, Courier New, sans-serif;
font-size: 0.9333em; /* 14/15 */
line-height: 1.28571; /* 18/14 */
}
<ul>
<li>Without any code - 18px height.</li>
<li>With <code>code</code> - 18px height.</li>
<li>With <code class="same-font">code.same-font</code> - 18px height.</li>
</ul>
Why Menlo?
I noticed that StackOverflow used Menlo and that didn't have this problem. When I tried it, it also solved the problem, however the font isn't built in on Windows.
So simply using Menlo solved the problem on Mac and didn't change anything on Windows.
Why the different font-size?
The different size changed nothing (except the font size...) when Menlo is in use - it still adhered to the line height, so Mac is all good.
However this font-size in combination with the Courier New fallback on Windows somehow got it adhering to the line height there too!
If I used 14px instead of 0.9333em it'd still work fine, but if I used 18px for the line-height instead of 1.28571, it wouldn't work. That doesn't bother me as I use relative values in my designs anyway.
So...
The Menlo font in combination with a Courier New fallback with a different font-size worked to solve my problem to a good-enough extent on Mac (Safari and Chrome) and Windows (Chrome).
My situation is lenient - a pixel difference wouldn't break my design, but just my rhythm. In cases where pixel perfection is required, I wouldn't feel safe with this voodoo method of playing with fonts and sizes...
If anybody can still explain where all of these numbers are coming from and what makes the actual difference here, that'd be great.
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 some icons that are set via pseudoelement in CSS, like this:
.button a:before {
font-size: 1.3em;
font-family: font-awesome;
content: "*";
}
And there are other, similar declarations elsewhere, like
.button .otherclass a:before {
font-size: 1.35em;
}
This works fine with modern web browsers, but IE >= 9 compounds all the font sizes, so that the resulting icon is enormous (like 5 times its size). How can I prevent this from happening?
(BTW, the actual code with the problem is here.)
This is a bug in IE, as reported on the Microsoft Connect page mentioned by #Aibrean, but the page also shows that Microsoft does not admit that this is a bug (they say they cannot reproduce it). It can be reproduced in IE 11 on Win 7 with the following simple document:
<style>
.foo, .bar:before {
font-size: 2em;
content: "X";
}
.bar:before {
font-size: 5em;
}
</style>
X<span class=foo>X</span>
<span class=bar>bar</span>
The second X should be 5 times as big as normal X, but it is actually 10 times as big in IE, since IE incorrectly multiplies the effects of 2em and 5em.
The workaround, it seems, is to organize your style sheet so that the font size of generated content is set once only for each element. That is, so that there are no two font-size declarations that apply to the same :before or :after pseudo-element.
There is a slightly better solution than using absolute font-sizes, and that is to use rem inside the :before or :after declaration.
em and rem units are based of the default font-size (commonly 16px, so 1rem = 1em = 16px) so if the user changes their default font then your font will change too. However rem units do not compound.
rem support is growing but you can use both (if you don't need compounding):
font-size: 2em
font-size: 2rem
and then those browsers (e.g. IE8) that don't support rem will use em. And as IE8 doesn't have the compounding issue to which you refer, this actually works nicely.
http://www.alecos.it/new/125027/125027.php this link is an example of my problem... I used a png 1x16 for drawing the rows... the rows are visible in the link posted... my question is:
why under IE 6/8, FireFox, Opera, Safari and other browsers the rows are perfectly aligned with the text while under IE 9/10/11 the text do not fit in the rows?
I used a simple css:
/* Style Source Code */
.code {
border-radius: 7px;
border: #6666FF 1px solid;
background-color: #FFF5EE;
background-image: url("../bkg/Bkg_116.png"); /* Horizontal Rows */
background-repeat: repeat;
background-position: 0 10px;
}
/* Style Source Code */
.xcode {
color: #008000;
font-family: 'Courier New', Courier, FreeMono, 'Nimbus Mono L', monospace;
font-size: 13px;
font-style: normal;
line-height: normal;
font-weight: normal;
font-variant: normal;
}
/* Style Div */
.alignment {
line-height: 20px;
text-align: justify;
}
Hope in workround to fix the issue...
here there is my css: http://www.alecos.it/css/alecos.css
I'm not on Windows machine right now but my guess is .xcode(line-height:16px;} would solve your problem, but I must say that this is the wrong way of creating row borders. Why not add:
.xcode td{border-bottom:1px solid #ddd;}
instead of using background image?
Firefox is temporarily outdated unti it's next update meaning that it's browser does not have the ability to process codes in the same manner as other browsers.
.alignment {line-height: 20px;}
Gets over ruled by .xcode line-height normal;
IE aint normal ;)
Besides content tages like h1, p, font all have slightly different margins/paddings around them. So a non responsive img isnt the best way to go.
Would be better if you could wrap each line with a span, div or sinces its a table a tr,td and give those a border-bottom.
Gr.
Kevin
In order to make your text inside .xcode aligned with the horizontal lines, the "code" lines must be distributed vertically. Unfortunately, It seems that you did not understand the meaning of line-height property and use the default value without considerations.
The line-height property
As you can see, the line-height property will decide how much is the distance of two lines of text. In your case, we need it to be exactly 16px inside the whole block of .xcode.
The value of normal value of the line-height property
From the W3C CSS spec, the value of normal value is defined as:
Tells user agents to set the used value to a "reasonable" value based
on the font of the element. The value has the same meaning as
. We recommend a used value for 'normal' between 1.0 to 1.2.
From some online resource like this article or this page, you can see that the real value of normal value depends on many arguments like font size, font family, OS, user agent, ... Therefore, it is recommended that you should use some css normalize stylesheet to set the value of line-height correctly and cross-browser.
About your case
The quick fix here is setting the line-height inside the .xcode class to be 16px (which is the height of the of your background image).
I have some buttons my page using a custom font face using the CSS and files generated by the Font Squirrel generator.
When the font's colour is black, they display fine...
However, when I change the colour to something else, the text seems to have a smoothing that bleeds the characters into each other and generally makes the characters look too thick...
I've played around with font-smooth property and a few other things, but have been unable to get it to work...
I don't think it's too relevant but the CSS for these buttons are...
color: #FFFFFF;
display: block;
padding: 1em 0.3em;
position: relative;
text-decoration: none;
z-index: 10;
font-family: BebasNeueRegular,Arial,Sans-Serif;
font-size: 22px;
list-style: none outside none;
text-align: center;
text-transform: uppercase;
The background is a separate element.
How can I get the white text to appear like the black text?
(It may be hard to tell the difference between the two, but my boss insists it is there.)
This worked for me:
-webkit-font-smoothing: antialiased;
Part of the problem is that it's not a particularly well-made font. I concur with #thirtydot's suggestion of text-shadow. A 1px black-on-black text-shadow should thin the font out. Any browser that doesn't support text-shadow will be rendering the font horribly anyway.
And remember that some html elements has bold as default, like h1, h2... When I use font squirrel to generate a font and use it with h1, for example, I always put:
font-weight: normal;