I'm working on a customers website and they insist I use EXACTLY the same font they had before. The previous (drupal) site had a Cascading Style Sheet callout:
body { font: 76%/170% Arial,sans-serif; }
As I understand it, that correlates to a Websafe font, where the browser looks to the users operating system and tries to match a font, in this case with Arial first and if not, Sans-serif. Nothing is downloaded from the web.
Based on my testing, the native font size seems to be 16px, and the native line height seems to be 20px. The fractional percentage numbers indicate font-size (as a ratio from 16px) and line-height (as a ratio from the calculated font-size). In this case font-size observed (via WhatFont) = 12.1667px and line-height of 20.6833px
The combination shown above seems to have been a very common Drupal selection, at least it would appear so from my Google searches on this topic.
This whole thing seems way odd. I would think...
body{ font-family: Arial, sans-serif; font-size:12px line-height:21px}
makes more sense, communicates the intent clearly for those who follow, etc. Why would anybody do the % / % system for identifying font-size? Is that native height ALWAYS 16px? This feels like obfuscation for nothing. Is there a significant advantage anywhere? Why would anybody code like this? What am I missing here?
Related
I have this string line which has for example exactly 100 characters.
I want to set it's font-size such that the line, starting at exactly pixel 0 of the web page, would end at the final pixel exactly.
The font is monospace so I assume so i assume i'm aiming towards setting the font-size to 1/100 of the window size.
PROBLEM:
* font-size refers to the height of the font! should i not expect a monospace font to be square ratio regard width and height?
An attempt:
<body>
<span>
123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_
</span>
</body>
body {
margin: 0;
font-family: monospace;
}
span {
font-size: 1vw;
}
this did not result in the wanted outcome. However, setting the font-size: 1.82 did result in it. But it's a bit shaky I guess to use such a random ratio setting and I was interested if there's a better way to go about it.
Step one is to not use font-family: monospace, because you are guaranteed to get different fonts on different browser/OS combinations. So use a real font, which leads to...
Step 2: use a real fond that you load as a webfont from your own server, so you control the exact version of the font people will be using. Because merely using a font by name in the assumption that font exists on everyone's OS, or even assuming something like google fonts will always only send one exact version, is guaranteed to fail, too.
And then step 3: look up what the em size as well as glyph width is that your chosen monospace font use, so that you can base your font-size on values that you know are applicable for every user, because you've ensured exactly which font will be used to style your content.
I am using Google font Open Sans and if I set the font to font-size 11px it looks big for the text I need and if I set it to 10px it looks small so I tested just for fun and set it to 10.5px and it works on Chrome tested 10,5px with , and it does not work.
Is this correct that we can set values of font size to example:
10.1px or 10.2px or 10.3px or 10.5px ? or is that incorrect or new css or beta something?
I really would like it to work like 10.5px because is exactly the font-size I need but reading and reading I find nothing about it.
If this works is it supported by all browsers and cellphones ?
Basically, the answer is that no, it is not a good approach if you want to make sure that your font renders precisely in a cross-browser fashion. There is no such thing as a half-pixel when it comes to rendering the font, so you leave yourself open to different browser-applied rounding effects which could differ from browser to browser and between client devices, which have different resolutions and pixel densities.
Convert your font size to a scalable unit like em or rem, and you can get what you are looking for.
By default, 1rem = 16px. so 10.5px = 0.65625rem.
The added benefit is accessibility. Some users may increase their default font size. Your text will scale accordingly if you use em or rem units. Pixel sizes won't.
Use percentage instead, you won't get the same size on different displays/browsers, but you should get more control over the size of your text.
e.g:
font-size: 98%;
This article may help.
I'm writing a webpage where I want to use one font for normal text and another for code, so I have the following CSS:
body {
font-family:Verdana, sans-serif;
font-size:100%;
}
code, pre {
font-family:Consolas, monospace;
}
This works except that the Consolas text comes out considerably smaller than the Verdana text. I can sort of fix it by adding font-size:1.2em; to the code, pre settings, but that feels like a hack, particularly since the number isn't derived from anything other than trial and error.
Is this something that happens to be a quirk of the particular fonts involved, or am I doing something wrong?
Alas this is because Consolas has a smaller x-height than Verdana. You can indeed "sort of fix it" by using a larger font size, but if the user doesn't have Consolas the page will fall back to the default monospace font, which will appear too large.
The proper solution lies in CSS3's font-size-adjust. Alas it isn't very well supported at all; as far as I know then only mainstream browser to support it is Firefox.
When you define a font-size in CSS, what you're doing is defining a concept known as an "em square" or "em box" even if you aren't using em units.
The em square gets its name because in the days of metal press printing, each letter was put in its own metal "box" and in traditional typefaces the uppercase Latin M typically filled the width of an entire box, defining the sizes for the entire family. Hence, the em box. Although the original em box was defined by the width of the M, the em unit itself refers to the maximum allowable height of a character. This was just a result of the box created for the uppercase M.
In short, all of the letters in a font family need to fit inside the em box, but they don't have to take up the whole thing. So when you set an em box with a given width, all you are doing is defining the maximum allowable space for the lettering to be placed in. From there, the typeface designer's choices in kerning, geometry, ratios, etc. will determine just how much of that box their lettering will take up. This is why you are having to use two different font sizes to make the lettering appear to be the same.
The font sizes are the same. But in Verdana, characters are generally taller than in most fonts (in the same size). For example, “H” in Verdana is taller than “H” in Consolas. This is a font design issue.
The solution is to use matching fonts. If you really want to use Verdana for copy text, Lucida Console is probably the best choice for a monospace font. If you want to use Consolas as monospace font (fine!), then use another “C font” for copy text, such as Cambria (serif font) or Calibri or Candara (sans-serif fonts).
Although the font sizes are the same here (on browsers that I tested), it is best to make sure of it, since browsers often apply something like font-size: 90% on code and pre and some other elements. The conditions for this to happen are somewhat obscure, and explicitly setting font family to something else than the generic monospace seems to prevent that on modern browsers. But it’s still a useful precaution to set
pre, code, samp, kbd, tt { font-size: 100%; }
The first line is in Verdana and the second is Consolas. Both 12pt. Consolas is slightly shorter, but not so much as in 20% difference. Check the parent elements of your pre, since em font sizes are cummulative - e.g. if body is 0.9em and pre is 0.9em, the result would be 12pt * 0.9 * 0.9 = 9.72pt
If you are trying to match only the height but ignoring the width, then 1.16em looks about right, and it is really the quirk of the font and you are not doing anything wrong.
Edit
Looks like you are doing nothing wrong =) Left is from fiddler, right is from WordPad
Consider the following example: (live demo here)
HTML:
<div>Hello World</div>
CSS:
div {
font-family: monospace;
font-size: 1em;
}
JS:
$(function() {
alert($("div").css("font-size"));
});
In Firefox, the font size is 16px, while in IE8 the font size is 13px.
Why ?
(I tried to change the font-family to Arial, and both Firefox and IE8 say 16px.)
Each browser is a different product by a different company, they program their product differently, and font size is one of them. From this link, 1 em is equal to the current font size, which maybe different for different browsers, also user can change it, i have changed the text size to largest in IE, and the font size is now 21.33 px.
Using em means it is dependent on a lot of things, use %age for consistency.
1 em will be different for different browsers (depending on their default or of user has changed it). For example you said IE has font size of 13 px and firefox has 16 px, when i checked, firefox had 13 px and IE has 16 px, which was changed to 21.33 px when i changed the text size to largest (view -> text size)
Because em is a relative unit. An em is equal to the current font-size. If the font-size of the document is 16pt, 1 em is equal to 16pt.
MSIE seems to think that monospace doesn't need to be as big as Arial (in pixels) to be readable. For example, 12pt Times New Roman is about a big as 10pt Arial.
If you want fixed font sizes, use font-size: 16pt.
Because its an implementation choice. For instance, firefox has a configuration option to set the default font face and sizes for Sans, Serif and Monospace.
Because Firefox builders messed up in how they coded "monospace". To get "monospace" to work properly in Firefox you need to type "monospace,;" not "monospace;".
I kid you not. It is that simple of a problem.
Check it out for yourself. Change your css style to have a comma after the "monospace" and before the semicolon and watch how dramatically it instantly changes the way that text appears.
Conventional belief was that you needed to have it type "monospace, monospace;" to work but they were wrong. That second "monospace" was meaningless, only the comma mattered. Which actually means you could have put anything there and it would have worked. So if you wanted to leave a funny easter egg in your code you could do something like "monospace, hellofromthecoder;" and it would function perfectly fine without that extra bit of text changing anything.
I have a Microsoft Word document which uses a 10pt Arial font. I have re-created this document with HTML/CSS, specifying font: normal 10pt Arial; in my stylesheet. When I print from the web page (from Chrome), the text appears significantly smaller.
I have my text wrapped in a 800px-wide container on my website. Might this be a cause? Besides this, to be honest I'm completely out of ideas & any help would be greatly appreciated.
It could be because you are specifying font sizes in pts. pts are pretty much inconsistent across platforms and do not scale. (px don't scale either) Try using em.
See Also: http://www.w3.org/QA/Tips/font-size, CSS Font-Size em vs. px vs. pt vs. percent
(You will have to provide a sample of your HTML to get a more concrete answer)
Have you tried converting your font-size to pixels or ems? I believe 10pt would roughly translate to 13px.