I've been looking around and can't seem to find a definitive answer to this.
How do I get font weights lighter than 600 to show correctly for textarea fonts?
Fiddle: http://jsfiddle.net/bk53K/
Code:
<textarea rows="7" class="randomText">Never gonna give you up Never gonna let you down Never gonna run around and desert you Never gonna make you cry Never gonna say goodbye Never gonna tell a lie and hurt you
textarea {
border: none;
resize: none;
font-size: 30px;
font-weight: 100;
}
Not all fonts are available in all weights. As the MDN states:
The font-weight CSS property specifies the weight or boldness of the
font. However, some fonts are not available in all weights; some are
available only on normal and bold. Numeric font weights for fonts that provide more than just normal and bold. If the exact weight given is unavailable, then 600-900 use the closest available darker weight (or, if there is none, the closest available lighter weight), and 100-500 use the closest available lighter weight (or, if there is none, the closest available darker weight). This means that for fonts that provide only normal and bold, 100-500 are normal, and 600-900 are bold.
Behavior will also vary by browser, font, and client OS.
You get font weights lighter than 600 (or lighter than 700 for that matter) by declaring a font that has a typeface with such a weight. Most fonts that people normally use on web pages don’t have such typefaces. In your case, no font is declared, so browsers will use their default font for textarea, normally whatever the generic name monospace maps to. It is virtually certain that it does not have any weight smaller than normal (700).
The practical way to get lighter font weights is to use suitable Google fonts. Most Google fonts have just normal and bold, but some have other weights too. The weight 100 is very rare, though.
If you wish to use a light monospace font for textarea, you might consider Source Code Pro, which is a simple sans-serif monospace font with weights 200, 300, 400, 500, 600, 700, and 900. Example:
<link rel='stylesheet' href=
'http://fonts.googleapis.com/css?family=Source+Code+Pro:300'>
<style>
textarea {
font-family: Source Code Pro;
font-weight: 300;
}
</style>
<textarea>Hello world</textarea>
Here's a great article about font-smoothing that might do the trick. I find using -webkit-font-smoothing: antialiased; brings my fonts much closer to their desktop weights than without.
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'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.
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?
I'm currently using {font-weight:bold} for an Arial font, but it seems to be too thick. Can I make things a little thinner? I cant find any other method to do it. I've used {font-weight:400} - Specifying in increments of 100. But it's the same thing. Too thick. Any other way to make a font a bit bolder than the other text?
There are many many many fonts that look like Arial that you can play with , some are bolder then others ,
Try looking for a font In Google WebFonts and you can attach it into your css to ensure it will work in every browser
The Arial font has no typeface with a weight between normal (400) and bold (700). Some other fonts do. So you might choose a different that either has an in-between weight or has a bold typeface that suits you needs and eye.
For example, the Google fonts Source Sans Pro and Open Sans are more or less similar to Arial, and both of them have a semi-bold (600) typeface.
It is possible to create sort-of fake bolding of different degrees using text shadowing, with the color being the same as text color, in CSS, e.g. text-shadow: 1px 0 black. But the result is poor. Genuine bolding is rather different from such artificial thickening of strokes.
Sorry man, but Arial Bold is not too thick as you say, It's just "Bold". (Arial Black or Alfa Slab is what then?). But if YOU feel it's too thick for you, you can try a webFont that have a light style and then you can use the regular one as as your Bold style.
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