How can I override the minimum-font-size in Firefox? - css

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;
}

Related

adjusting font-size according to the displayed system-font in a stack via css

Font stacks offer the possibility to suggest an ordered list of fonts a browser should display if it either is installed on the client system or if it is provided via an #font-inclusion over the server – so far so good. But sometimes optical similar fonts have big differences in display size. For example Lucida Grande would be a good choice as a substitute for Calibri. But the difference in size is more than 20%: The word TEST with font-size: 50px; and Calibri is 95px wide whereas it takes 118px with Lucida Grande.
So, here is the question: Is it somehow possible to detect the font which is actually displayed in the browser and adjust the font-size accordingly in CSS? I want to avoid JavaScript on this because it is just a layout problem.
Nice would be something like this:
font: 400 50px/1 'Calibri', 400 40px/1 'Lucida Grande';
or
font-family: 'Calibri', 'Lucida Grande';
font-size: 50px, 40px;
But too bad – this doesn't work!
Edit: This is a "academic" question. I know, I could use JavaScript and I know, I could just buy the web font and quit worrying and get a beer – but I just like to know if somebody has a smart workaround for this!
Is it somehow possible to detect the font which is actually displayed in the browser and adjust the font-size accordingly in CSS?
The answer is NO.
And I could only give the advice not to base your layout on "knowing how width and/ or height" any (text) element/ node would be!
Websites aren't meant to be pixel perfect drawings - it is not print design.
There are so many (unforeseeable) circumstances that may effect the used font and/ or font size, that any attempt to make them as intended, will most probably fail.
The only thing you may try is using Javascript to get the width/ height of an element and to adjust the font-size as long as the size fits your needs.
There are some scripts out there for this.
One is FitText

Why does my google font have inconsistent weight in multiple parts of the same character?

I was wondering if someone could point me in the right direction. I am looking to display the Google Font Orbitron at consistent weights at every given font size. Sounds pretty easy, right? Not in my scenario. At certain font-sizes, some characters have multiple weights within the same character.
Note: I am testing this in Windows 7, Chrome v27
The Code:
<link href='http://fonts.googleapis.com/css?family=Orbitron:400,500,700,900' rel='stylesheet' type='text/css'>
.sixteen{
font-family: Orbitron;
font-weight: 400;
font-size: 16px;
line-height: 22px;
}
.nineteen{
font-family: Orbitron;
font-weight: 400;
font-size: 19px;
line-height: 22px;
}
<h4 class="sixteen">Home of Front End Developer and</h4>
<h4 class="nineteen">Home of Front End Developer and</h4>
Here is a fiddle to explain my issue. If you take a look at the fiddle, you'll see in the first line that the top line of the uppercase F, E, and D characters have more weight/thickness than the rest of the characters in that line. But as you'll notice on the next line, that
In case you cannot replicate what I'm seeing, here's a screenshot:
My question is two-fold:
What would the best way to technically describe this? 'Multiple font weights in one given character' lacks brevity, and isn't likely to have any valuable Google results.
Is there a way to fix this and make the weight consistent in every character at every font-size?
What you describe is as such just variation of the visible width of strokes in glyphs, or stroke width variation to put it briefly. Such variation is normal in serif fonts and also appears, at least to some extent, in many sans-serif fonts. However, in this case, the font is designed to have a rather constant stroke width, so the visible effect is caused by font rendering differences.
There is no way to remove the font rendering differences. Font rendering is a complex issue, and although some proposed or experimental CSS settings might affect some aspects of it, it’s basically outside your control. For example, font smoothing (also known as anti-aliasing) depends on the operating system and its settings as well as the browser and its settings.
I've found this issue with a bunch of fonts used online when you go down to a certain size. It's the way the font is being anti-aliased.
You can see the same issue from Google showing off that font: http://www.google.com/fonts/specimen/Orbitron

Is "line-height: normal;" a bad idea?

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

#font-face and line-height issue

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

body { font-size: 100.01%; } vs body { font-size: 100%; }?

What should i keep for body, {font-size: 100.01%; } or { font-size: 100%; }?
what is {font-size: 100.01%; }? and is it really good to mention font-size in html{} even
If I'm using body {font-size: 62.5%;}
Edit : 3 May 2010
Today i found info about 100.01% at here - http://www.communitymx.com/content/article.cfm?cid=FAF76&print=true
This odd 100.01% value for the font
size compensates for several browser
bugs. First, setting a default body
font size in percent (instead of em)
eliminates an IE/Win problem with
growing or shrinking fonts out of
proportion if they are later set in
ems in other elements. Additionally,
some versions of Opera will draw a
default font-size of 100% too small
compared to other browsers. Safari, on
the other hand, has a problem with a
font-size of 101%. The current "best"
suggestion is to use the 100.01% value
for this property.
Is it good to keep body { font-size:100.01%} in place of {font-size:100%}
The declaration body (or html) { font-size: 100.01% } compensates rounding errors, in particular in older versions of Opera and Safari. Both would otherwise display fonts that are too small.
A relative font-size (%, em) is always interpreted relative to the font size of the parent element. So it's not a bad idea to implement kind of a initial reset in the top element, which you can achieve with body {font-size: 100%}.
Never seen 100.01% before, but it seems like some sort of browser hack that will force some browsers to ignore or calculate size correct if you use this "fix".
I wouldn't use it myself though, as errors tends to be fixed and there are often more nice ways of dealing with the same option.
html {
font-size: 100.01%;
}
100.01%, not a hack or a kludge, has been around for many years. Google "100.01%" and read up. It is as valid as 100% and does cover some territory 100% doesn't.
An initial font-size should always be declared. Set a base font-size on an outer container -- either <html> or <body> -- for it is from that container which all relative and inherited font-size values will derive. Using 100% or 100.01% makes the starting font-size equal to the user's browser preference.
Setting that base font-size to the user's browser preference gives your visitors maximum readability. Read that again, please, about the USER's preference. Your visitor will have set their browser font-size for their own best legibility and reading comfort. Your design, magnificent and fragile though it may be, is only a second-string player. Content is king, assuming you have some. But if that content is un-readably tiny, you lose. The visitor surfs on. Your design, then, has failed your needs and your expectations. Therefore, the design really wasn't all that great, was it?

Resources