How to Override the Minimum-Font-Size in Firefox

Why does Firefox not honor CSS font-size for code tags wrapped in pre?

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.

Workaround for showing font size 1000px?

Use css transforms instead, like:

transform:scale(200%,200%);

Increase code font size in firefox developer tool

You need to modify userChrome.css under ~/.mozilla/firefox/[profile-name]/chrome with this:

/*  Styles for Web developer tools */
@namespace url(http://www.w3.org/1999/xhtml);
.CodeMirror {
    font-family:    "Ubuntu Mono", monospace !important;
    font-size:      15pt !important;
}

The result looks like this:

firefox

This only changes the debugger and style editor. There's a different selector for the html inspector. Not sure what that is yet.

REM font size not adjusting below arbitrary threshold

Chrome and its Blink rendering engine seem to have some non-obvious font-scaling rules. I'm unaware of any official comprehensive documentation, so let's go to the source.

(Note that I'm not an expert on Chromium internals generally or Blink renderer particularly. I've just been tracing through the source code and speculating on the most probable answers to the questions as posed.)

It seems to me that the engine calls upon the FontBuilder class during a redraw. This class has various dispatch methods that pass the DOM, zoom, and other relevant factors into what appears to be the crucial method: FontSize :: getComputedSizeFromSpecifiedSize. In that method, we see some juicy comments that address the points you've raised:

1. Why does setting font-size: 0; to a parent element fix it?

  // Text with a 0px font size should not be visible and therefore needs to be
  // exempt from minimum font size rules. Acid3 relies on this for pixel-perfect
  // rendering. This is also compatible with other browsers that have minimum
  // font size settings (e.g. Firefox).

2. Why is it not honoring the rem size below a certain threshold?

  // We support two types of minimum font size. The first is a hard override
  // that applies to all fonts. This is "minSize." The second type of minimum
  // font size is a "smart minimum" that is applied only when the Web page can't
  // know what size it really asked for, e.g., when it uses logical sizes like
  // "small" or expresses the font-size as a percentage of the user's default
  // font setting.

  // With the smart minimum, we never want to get smaller than the minimum font
  // size to keep fonts readable. However we always allow the page to set an
  // explicit pixel size that is smaller, since sites will mis-render otherwise
  // (e.g., http://www.gamespot.com with a 9px minimum).

3. For the curious, what are these minimum values when given relative units (eg x-small)?

// Strict mode table matches MacIE and Mozilla's settings exactly.
static const int strictFontSizeTable[fontSizeTableMax - fontSizeTableMin +
                                     1][totalKeywords] = {
    {9, 9, 9, 9, 11, 14, 18, 27},    {9, 9, 9, 10, 12, 15, 20, 30},
    {9, 9, 10, 11, 13, 17, 22, 33},  {9, 9, 10, 12, 14, 18, 24, 36},
    {9, 10, 12, 13, 16, 20, 26, 39},  // fixed font default (13)
    {9, 10, 12, 14, 17, 21, 28, 42}, {9, 10, 13, 15, 18, 23, 30, 45},
    {9, 10, 13, 16, 18, 24, 32, 48}  // proportional font default (16)
};
// HTML       1      2      3      4      5      6      7
// CSS  xxs   xs     s      m      l     xl     xxl
//                          |
//                      user pref

Interestingly, and a bit of an aside, the FontBuilder class dispatches to TextAutosizer :: computeAutosizedFontSize to scale the font size. This method uses hard coded values and a variable scaling factor:

  // Somewhat arbitrary "pleasant" font size.
  const float pleasantSize = 16;
  // Multiply fonts that the page author has specified to be larger than
  // pleasantSize by less and less, until huge fonts are not increased at all.
  // For specifiedSize between 0 and pleasantSize we directly apply the
  // multiplier; hence for specifiedSize == pleasantSize, computedSize will be
  // multiplier * pleasantSize. For greater specifiedSizes we want to
  // gradually fade out the multiplier, so for every 1px increase in
  // specifiedSize beyond pleasantSize we will only increase computedSize
  // by gradientAfterPleasantSize px until we meet the
  // computedSize = specifiedSize line, after which we stay on that line (so
  // then every 1px increase in specifiedSize increases computedSize by 1px).
  const float gradientAfterPleasantSize = 0.5;

From these facts, we see there are a good number of hard-coded pixel values, with 9 and 16 being commonly sprinkled about the relevant code. These hard-codes, the presence of several rules to scale the font down to a limit, with the ability to override using font-size all seem to match the observations and suggest it's behaving as intended -- if not necessarily intuitively.

Also, I've found that the most recent comment posted in Chrome bug #319623 very much resembles your report.

Possibly related: when using relative units on the html tag, rem-based values defined elsewhere will have a lower bound of 9px.

See CodePen: http://codepen.io/larrybotha/pen/wKYYXE

Workaround: absolute unit on html, em unit on body. rems everywhere else.

It may be prudent to watch that bug for further developments, though maybe not with breath held. The last update was in 2015.

Override default font-size of password inputs in Chrome to match Firefox

Here you go (using a media query to select Chrome... and Safari, which I don't have to check):

<input type="password" class="pass" value="dfjlfsdkljf"><br>
<input type="password" value="dfjlfsdkljf">

@media screen and (-webkit-min-device-pixel-ratio:0) {
    .pass {
        -webkit-text-stroke-width: .2em;
        letter-spacing: 0.2em;
    }
}

http://jsfiddle.net/exbFb/3/

And a blanket selector, to affect a input[type=password] elements:

@media screen and (-webkit-min-device-pixel-ratio:0) {
    input[type=password] {
        -webkit-text-stroke-width: .2em;
        letter-spacing: 0.2em;
    }
}

http://jsfiddle.net/exbFb/4/

how decrease font size?

That is a rule specified by the browser, usually 10px is the minimum font size allowed in a default Firefox installation.

Try it by going to Preferences -> Content -> Fonts & Colors -> Advanced -> Minimum font size.

Any font size smaller than 10px will be almost non-readable. The rule is there to ensure better accessibility.

Hope that helps.