Image below displays the result for:
div.test { background: #00F; font-size: 50px; line-height: 50px; color: #FFF; margin: 50px 0; font-family: Wiesbaden; }
One using Wiesbaden (which is font-face) and the other without.font-face font seem to ignore the line-height property.
Is it font-face issue or the font?
The property line-height only specifies the vertical distance between the start of one line and the start of the next. If you typed out something that took up two lines, the start of the 2nd line should be in the same vertical position using either font.
It seems like that's just how your font looks at 'font-size: 50px'. If you wanted to, you could increase the font-size while keeping line-height: 50px to correct it.
In short, it's not an issue with either. They're behaving exactly how they should be. See your blue background? That's your line-height. Line-height doesn't affect the font itself, but rather the spacing of the lines of the text.
Some fonts are different sizes even when set to the same font-size. It's the way the glyphs are rendered. If you want your text larger, increase the font size. If you want fallbacks to be the same size, you can use similarly-sized fonts (look up "font stack generators" for help on this), or check out the CSS3 font-size-adjust property (do note that it is CSS3, so you'll want to double-check support of it).
I had a similar issue, but I used a Cufon script instead of fontface to avoid browsers issues. To solve my line-height issue I changed the doctype from transitional to strict. Try that.
The following fiddle illustrates the differences between 4 fonts (3 being very common fonts found on Macs, PCs, etc). One is a Google-font. Regardless, 4 fonts - four different results. If a design is going to rely heavily on a 'non-standard' font, be sure the fallbacks don't blow the whole thing up.
Pay particular attention to the differences in:
the top spacing between the capital Q and its parent's border
the various heights of the Xx (especially, the lower-case vs capital)
descender of the lower-case G (some actually come out of their
parent)
_http://jsfiddle.net/suK2U/
I tried this and it works perfectly!! just play with percentage until you find the needed result.
Apply this on your #font-face:
ascent-override: 90%;
Hope it helps!
More info:
https://developer.mozilla.org/en-US/docs/Web/CSS/#font-face/ascent-override
Related
I must have went through every page of google but haven't found the solution yet. I have a custom font that I'm using through css font-face. The font adds extra padding on the bottom depending on the browser and OS that I am using. The picture below shows an example with mac being on the left and windows on the right. It looks correct on the right (in windows) and i want it to be the same on mac.
#font-face
{
font-family: universLight;
src: url('http://www.viggi.com/fonts/UniversLTStd-Light.otf');
font-weight: normal;
font-style: normal;
}
#button{
font-family: universLight;
border: 1px solid black;
background: #ccc;
}
The code is located at http://jsfiddle.net/ZDh5h/
Here is what I already know won't work from my research.
line-height adds padding to the top and bottom so the extra padding on the bottom remains.
using different extensions such as .otf or .ttf also doesn't work. Just produces the same results
changing the font-size also doesn't really do anything
I use this font a lot through out the site and don't really want to add different CSS sheets for mac vs windows. If anyone knows anyway to fix this without having javascript add extra padding I will be very grateful.
Thank you.
See http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
normal
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.
The computed value is 'normal'.
I think the behaviour you observe comes from different "reasonable" values across browser as normal is the default line-height value.
So specify your value (say line-height: 1.5em;) to get rid of the differences.
I've began working on a new site using REM units with PX fallbacks. Now, I have a question that may be silly, but I can't find anything specifically mentioning it so I'll just go ahead and ask here.
Using property shorthands and specific properties seems to both load take effect in the browser Chrome.
body{ font:16px/23px sans-serif;
font-size:1rem;
line-height:1.438; }
whereas using both shorthand or both specific properties cancels one or the other out (e.g. uses primary or fallback, not both)
body{ font-family:sans-serif;
font-size:16px; font-size:1rem;
line-height:23px; line-height:1.438; }
or
body{ font:16px/23px sans-serif;
font:1rem/1.438 sans-serif; }
Now which is exactly best practice here? All examples validate.
Is there a reason why the shorthands AND specific properties both load in the browser Chrome even though they're targeting the same properties? Are they actually both loading?
Does this have any adverse effects to how the browser/device is rendering the styles?
I've only looked into this via Chrome and I haven't been able to discern any differences through testing. But, You can see how it would be a little bulky if you HAD to use two iterations of the same code for all elements using rem's.
UPDATE:
Tested only in latest versions of all browsers below, all tests pertain to the first code snippet
In Firefox this doesn't seem to be an issue, it just replaces the font-size/line-height in the shorthand code with the rem sizing.
In IE, safari, & Opera it takes the shortcode and separates it into specific properties, but still loads the rem units ignoring the px units.
It seems to be specific to Chrome, at least in modern versions. So the question now, how to figure out how Chrome is handling it? The image, displayed at the bottom of this post, may explain a little more. See how BOTH font properties are loaded and neither are ignored or take precedence?
UPDATE#2:
When using margins, Chrome acts properly. I'll use the following "off the wall" example to demonstrate:
margin:16px 0 19px 0;
margin-top:1rem;
margin-bottom:1.188rem;
reads in chrome as:
margin:1em 0 1.188rem 0;
(source: leftdeaf.com)
This two resources will answer all of your questions:
http://snook.ca/archives/html_and_css/font-size-with-rem
http://blog.typekit.com/2011/11/09/type-study-sizing-the-legible-letter/
With line-height, use the unit, but not the value:
body {
font:16px/23px sans-serif;
font: 1rem sans-serif;
line-height:1.438;
}
or
body {
font-size:16px/23px;
font-size: 1rem;
font-family: sans-serif;
line-height:1.438;
}
You can't use FONT and FONT-SIZE, just use one or the other. Otherwise the browser will attempt to use both.
After a lot of wasted time and confusion... It actually does render correctly in Google Chrome. feeling silly now... I overlooked the drop-down arrow to the sub-properties in the Chrome Tools. Image displays what I overlooked. Example shows multiple examples of shorthand properties and specific properties, more importantly it shows the font property working, it wasn't crossed out but it was still being overridden. Not sure why it doesn't comply with the strike through like everything else, probably due to the font-weight, variant, style properties remaining unchanged. But it works.
I have observed some rather inconsistent HTML page rendering behavior when CSS line-height property is set to normal. I have also found a blog post by Eric Meyer where different inconsistencies of line-height: normal; are discussed, here is just one quote:
Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also vary within a given face.
In my case i observed that adding some Unicode symbols, for example the envelope symbol "✉", changes the line block height if line-height is set to normal. Setting line-height: 1.2; fixes the problem.
My question is: is there any reason at all to use line-height: normal;? It behaves so unpredictably.
In principle, a normal value for line-height (either via defaulting, or by explicit setting) is “normal”: browsers are expected to use a value that is suitable for the font being used. This variation should not be a surprise: it’s implied in the definition.
This is supposed to help with a problem like this: you declare font-family: a, b, c, d, sans-serif, but you don’t know which of the specific fonts (if any) is available in each computer, or what the default sans-serif font might be. These fonts might require different line heights, for good appearance. The browser knows which font it is using, so it can pick up a line height for it, from its internal table.
On the practical side, browsers might not select the value well; it tends to be generally a little too small. On the typography side, line height should be selected on the basis of several considerations, not just font face but also the type of text (e.g., texts with a lot of diacritic marks require larger line height) and especially the measure (column width, line length): long lines require larger line height.
So in general, it is best that the designer sets the line height, with due consideration of the different aspects.
This also avoids the problem you describe: when a line contains glyphs from different fonts, each font may have a different default line height associated with it. For example, the envelope symbol is included in a few fonts only, so the odds are that the browser is forced to pick it up from a font different from the one you have declared.
This is what causes uneven line spacing when you mix fonts. It’s not the height of the glyph that matters but the line height of its font. For example, adding a mere period “.” in Cambria Math font, when available, causes huge line spacing—unless you set line-height to a specific value.
is there any reason at all to use line-height: normal;
Yes - the property is there so you can use it when you specifically have to reset line-height to browser default in case you've set it somewhere on parent element.
Why and when you would want to do that depends on what you are implementing and whether or not you care about crossbrowser pixel perfect designs or not.
"normal" is the default value for "line-height". You explicitly declare line-height: normal to over-ride.
Example:
h1 {
line-height: 150%;
}
h1.normal {
line-height: normal;
}
If you look at the above snippet I have declared a line-height of 150% for h1 tag. In-case I want a particular h1 tag to behave normally [browser specific line-height], then I over-ride it using "normal"
Its true the normal line height varies on different browsers
It's better to see a bug for yourself in Firefox: http://jsfiddle.net/kizu/btdVd/
The picture, showing the bug:
And the bug filled in 2007 on bugzilla.
The bug appears when you're adding ::first-letter pseudo-element with display: inline-block, and then change the font-size of this first-letter.
More letters in a word after the first: more extra space added (or subtracted — if the font-size is lesser than block's).
Adding float: left to the first-letter inverts the bug: with bigger font-size the width of inline-block shrinks.
So, the question: is there any CSS-only workaround for this bug? It's somewhat killing me.
I've found that triggering reflow on the whole page (or any block with a problem) fixes the problem, so I've found a way to trigger it on every such block with one-time CSS animation: http://jsfiddle.net/kizu/btdVd/23/
Still, while this fix have no downsides in rendering, it have some other ones:
it would work only for Fx5+ (that supports animations);
it still flashes the original bug for a few ms, so it's maybe somewhat blinky.
So, it's not an ideal solution, but would somewhat help when Fx4- would be outdated. Of course, you can trigger such fix onload with JS, but it's not that nice.
I don't think there's a good solution.
I have come up with a flaky solution for you though:
.test:first-letter {
font-size: 2em;
letter-spacing: -0.225em;
}
Add the letter-spacing style to the :first-letter selector in your Fiddle, and you'll find the blocks go back to roughly the right size.
Explanation:
Basically, the bug is being caused by the whole block taking its size from the font specified in the first-letter.
What I'm doing here with the letter-spacing is trying to adjust the size of this font, without affecting it's physical appearance. Adjusting the letter spacing in this way in normal text would result in the letters overlapping each other by .225 of a character width on either side.
I was initially hoping that a value of -0.25 would be sufficient -- ie a quarter of a character on each side would reduce the width of each character by half, which would be what we want because the first letter is font-size:2em, so it's twice as big.
However, the calculation isn't quite as clean as that, because the first and last characters in the string would only be overlapped on one side each, and because the first letter does in fact want to be double width, even if the rest of the characters don't.
All of this means that the exact letter-spacing value required to counter-act the bug will vary depending on how long the text, as well as the font sizes of the original text and the first letter. This is why I had to experiment a bit with the value of the letter spacing to get it working, and also explains why I couldn't get quite a perfect fit on all the text rows in your Fiddle. I would have needed a slightly different value for each block.
The value of -0.225 seems to be about the closest I can get to it being right for all your examples, but in practice you'll need to adjust it to suit your site.
Don't forget also that this is a Firefox bug, and therefore you'll need to write it in as a browser-specific hack of some sort. And be careful to keep an eye on the Firefox bug report you linked; when it does get fixed, you'll need to work out a way to keep your hack in place for users of old versions, but remove it for users with the fix.
[EDIT]
The only other working solution I've come up with is simply not to use the features which trigger the bug. ie drop the :first-letter selector, and use a separate <span> for the first letter of your text if you want to style it differently.
This is the obvious answer really, and would of course solve the problem (and would also mean that your styled first letter works in older browsers), but it would not be ideal from a semantic perspective, and more importantly doesn't actually answer the question, which is why I didn't offer it as a solution in my original answer.
I have been trying to find alternative work around for the bug as well, but the options are limited, and nothing I've tried has given as good results as my initial suggestion.
I tried a hack of making the :first-letter invisible, and using :before to display the big leading capital letter. However, this didn't work for me. I didn't linger on it too long so you may be able to get it working, but there is a problem with it in that you'd have to define the leading letter in your CSS, which wouldn't be ideal.
Another possible solution is to use the CSS font-stretch: condensed; property on the :first-letter. This would reduce the width of the first letter back to 1em, and thus resolve the width issue of the rest of the text. The down sides of this, however, are that firstly it would make the leading letter look squashed, which is probably not what you want, and secondly this style only works for fonts which support the condensed property. It turns out that this isn't well supported by the standard fonts, so may not be workable for you.
In the end, the original letter-spacing solution is still the only way I've found to really work around the bug.
This bug still exists, but some of the fixes don't work anymore. Even after triggering a reflow with an animation, the inline-block returned to the same size for me. I couldn't use the letter-spacing trick because I am already using it on the first letter, that is what is causing the problem for me. I solved the problem by adding this to the CSS for the affected selector:
-moz-padding-end: *number of pixels to compensate*;
At the moment, moz-padding-end seems to be specific to Firefox, and it can add or remove width to the end of the inline-block. Because this is a Firefox specific bug, that did the trick for me.
I know this thread is quite old now, but apparently this bug has not been fixed yet.
Using animation does work but there is a noticeable FOUT (Flash Of Unstyled Text). I was able to work around the problem by wrapping the first-letter in a span. This does work around both the sizing issue and the FOUT, it does add extra elements to the markup, so it depends on the needs of your site/application if this is the best fit.
.test {
background: rgba(0,0,0,0.15); /* For visualisation */
display: inline-block;
}
.test:first-letter {
font-size: 2em;
}
.test2:first-letter {
float: left;
}
.test3:first-letter {
font-size: .5em;
}
<h1>Inline-block with bigger first-letter</h1>
<span class="test">Broken</span>
<br><br>
<span class="test"><span>F</span>ixed</span>
<h1>+ floating to first-letter</h1>
<span class="test test2">Broken</span>
<br><br>
<span class="test test2"><span>F</span>ixed</span>
<h1>small size for first-letter</h1>
<span class="test test3">Broken</span>
<br><br>
<span class="test test3"><span>F</span>ixed</span>
<h1>small size, floating first-letter</h1>
<span class="test test2 test3">Broken</span>
<br><br>
<span class="test test2 test3"><span>F</span>ixed</span>
As of 2023, this is still happening in Firefox.
This is my solution using SASS, but you can see how to make it bare CSS:
txt-brand {
display:inline-block;
}
///Firefox only ///
#-moz-document url-prefix() {
margin-right: .1em;
white-space: nowrap;
&::after {
content: '\00a0';
}
}
}
.txt-brand::first-letter {
letter-spacing: -.11em;
}
My site displays just like I need it to in IE and Opera, but in Firefox I can't use CSS to get font sizes smaller than Firefox's default minimum-font-size. Of course, I can go to Tools → Options and remove this value, but some users will see some of the elements displaced.
I have tried using !important, but it doesn't work, and I can't substitute the images for the text since they are dynamic fields.
Okay. I'm going to explain how you do this, but you need to know a few things first.
1. You shouldn't be doing this.
There is a reason, and a very good one, that the minimum font size setting exists. Simply, with most fonts, it is already a struggle to read anything below 12px, never mind below the default minimum of 9px. If your design calls for such font sizes for anything but an extremely restricted set of circumstances¹, then your design is just bad and excludes a huge category of users.
2. You really shouldn't be doing this.
The web is an intrinsically flexible medium, and a good design must take account of this. Designs that require a fixed font size to work are suitable for print, but they are not suitable for the web. Any designer who cannot work with this requirement does not understand the medium, and no decent PM should prioritise a designer's bad decisions over practicality and usability. You have far bigger, more fundamental problems to deal with if you can't argue against this decision.
3. You really, really shouldn't be doing this.
Depending on your jurisdiction, you may be wandering on a legal grey area. Tiny font sizes are difficult to read, and will make it very easy for your users to miss information—which is especially troublesome if the text at hand is legally significant, such as opt-out information or a disclaimer. You are also treading on thin ice with respect to the accessibility of your site by causing serious problems for people with visual impairments.
How to do it anyway
It is quite easy to make Firefox display fonts at less than the minimum specified size: just use the font-size-adjust property.
Here comes the science bit
Every font has something called an aspect value, which is the ratio between its x-height (the height of a letter x)² and the actual font-size you set. In Comic Sans, for example, this is really big (0.55), as you can tell by how big the shorter letters (a, c, e…) are compared to taller letters (b, d, h…), whereas in Courier New it is a lot smaller (0.43).
This variability can cause some problems. For example, let's say you specify a super-fancy font for your body text, but because you're a good designer you provide several fallback fonts. That's great, but because some of those fallbacks have different aspect values, letters might be smaller and less legible at the size you specified. font-size-adjust allows you to make sure that any fallback has the same x-height as your super-fancy font.
Unfortunately, we can also use it to make text less legible. Let's say your body copy is Segoe UI at 12px:
body {
font-family: "Segoe UI";
font-size: 12px;
}
The aspect value of Segoe UI is almost exactly 0.5, so if you specify that as the font-size-adjust value, your font size doesn't change:
body {
font-family: "Segoe UI";
font-size: 12px;
font-size-adjust: 0.5; /* x-height = 12px × 0.5 = 6px */
}
What happens if we set it to something smaller? Well, the browser will adjust the font size to use an x-height equal to font-size × font-size-adjust. The below, for example, will result in an effective font-size of 6px:
body {
font-family: "Segoe UI";
font-size: 12px;
font-size-adjust: 0.25; /* x-height = 12px × 0.25 = 3px */
}
This forms the basis of our attack. It turns out that Firefox will honour font-size-adjust even if it overrides the minimum font size. (It goes without saying that this is a bug.)
The demo
Try this out in Firefox with a minimum font-size set. It exploits two bugs: the aforementioned font-size-adjust issue and a separate issue with reporting the rendered font size via getComputedStyle.
You need to know the aspect value of the font you are using for this to calculate the right font-size-adjust value, for which this list of aspect values might help you. (Alternatively, try an estimated x-height for fonts installed on your system.)
But wait! There's worse!
The above technique only works in Firefox. It's even easier to override the minimum font size on an element in Webkit, including Safari, iOS Safari and Chrome—just use the non-standard -webkit-text-size-adjust property:
-webkit-text-size-adjust: none;
This is another bug, by the way. text-size-adjust is a non-standard proposal intended to limit the extent to which text-size is automatically inflated on mobile devices. It isn't meant to work on desktop UAs, much less prevent manual text resizing.
Last word: it won't last forever
Bugs get fixed eventually. You are not meant to be able to override the browser's default font size, no matter how much your irresponsible designer and PM want you to. Sooner or later, people will figure out that these properties are being exploited to make the web worse for everybody, someone will land a patch and the fun will be over.
That said, if you are being forced into this, I wholeheartedly advocate a solution that will eventually force the parties involved to rethink their decision.
¹ Hint: if your text conveys any information that is meant to be readable by anyone, ever, then you shouldn't be messing with browser accessibility settings. Legitimate cases include purely decorative effects (complex ASCII art, shape poetry) and document previews.
² More correctly, the distance from the baseline to the median height, which is the height of a letter x in most fonts.
You cannot do it. It's a setting that Firefox provides so that people like us cannot override it with some CSS settings.
You can effectively shrink text below the minimum size using CSS3's transform: scale(x) syntax, where x < 1. This is guaranteed to work in future browsers (as that's the point of scaling), but does come with its own challenges/caveats.
Just in case it might help anyone, I ended up replacing the small text areas, initially in HTML, with SVG zones. I fill these zones with the Raphaël JS library, with code like
logo_text = $j("#logo_text").val();
logo_text_preview_paper.clear();
logo_text_preview_paper.text(0, 4, logo_text).attr({"font-family": 'Helvetica', "font-size": 7, "text-anchor": 'start'});
I did not use an HTML canvas, because of its lack of availability on certain browsers, and because SVG offers a much better user experience on Retina displays.
It might seem overkill to do that, but I was not able to find an easier solution to the Minimum Font Size problem of FF.
In some cases you can use <canvas> element and fillText().
If you set the default CSS font size in your web pages to a percentage ... then through em sizing you can provide cross-browser scalability ... Setting the font size to 62.5% is a basis for rescaling fonts base hx sizes to 10px.
body {
font-size: 62.5%;
}
p {
font-size: 1em;
}
So if you really wanted to make your standard paragraph text say 10px ... You would just state it in your CSS as 1em and it would render as 10px. Please note that if you really want to do this correctly ... you need to do a CSS reset too as you want your display to be consistent ...
Eric Meyers CSS Reset
HTH
you can try the following code
body {
min-font-size: 15px!important;
}
If you set the the font size attribute on the body it should set it as default font size.
body
{
font-size: 12px;
}