Using Rems with a Pixel Fallback

using rems with a pixel fallback

Both of your style declarations will work fine. CSS renders code in a cascading fashion, this means if one value is declared after another, the latter will be used. If a browser can render px but cannot render rem, the rem values will simply be ignored. If a browser can render both px and rem, the latter of the two will be used:

h1 {
    font-size: 12px; /* 1. Font size set to 12px */
    font-size: 1rem; /* 2. Font size set to 1rem, overriding previous value */
}

In this example, rem will be used on browsers which support that unit, and px will be used on those which do not.

h1 {
    font-size: 1rem; /* 1. Font size set to 1rem */
    font-size: 12px; /* 2. Font size set to 12px, overriding previous value */
}

In this example, px will be used on both browsers which support rem and browsers which do not.

Can I Use... will give you a better overview of which browsers support this unit.

As for performance, each character contained within a CSS file equates to 1 byte. The more bytes contained within your stylesheet, the longer it will take a browser to download it. So of course, adding px values alongside rem values will ultimately add to the download time, but most of the time this is negligible.

As for whether Android devices come bundled with Chrome: no, this is not the case. This is entirely up to the manufacturer.

Which fallback is best when using rem as font-size unit in a responsive environement?

Seems best to use this polyfill https://github.com/chuckcarpenter/REM-unit-polyfill instead of fiddeling with fallbacks.

Should I use px or rem value units in my CSS?

TL;DR: use px.

The Facts

First, it's extremely important to know that per spec, the CSS px unit does not equal one physical display pixel. This has always been true – even in the 1996 CSS 1 spec.
CSS defines the reference pixel, which measures the size of a pixel on a 96 dpi display. On a display that has a dpi substantially different than 96dpi (like Retina displays), the user agent rescales the px unit so that its size matches that of a reference pixel. In other words, this rescaling is exactly why 1 CSS pixel equals 2 physical Retina display pixels.
That said, up until 2010 (and the mobile zoom situation notwithstanding), the px almost always did equal one physical pixel, because all widely available displays were around 96dpi.

Sizes specified in ems are relative to the parent element. This leads to the em's "compounding problem" where nested elements get progressively larger or smaller. For example:

  body { font-size:20px; } 
  div { font-size:0.5em; }

Gives us:

  <body> - 20px
      <div> - 10px
          <div> - 5px
              <div> - 2.5px
                  <div> - 1.25px

The CSS3 rem, which is always relative only to the root html element, is now supported on 99.67% of all browsers in use.

The Opinion

I think everyone agrees that it's good to design your pages to be accommodating to everyone, and to make consideration for the visually impaired. One such consideration (but not the only one!) is allowing users to make the text of your site bigger, so that it's easier to read.

In the beginning, the only way to provide users a way to scale text size was by using relative size units (such as ems). This is because the browser's font size menu simply changed the root font size. Thus, if you specified font sizes in px, they wouldn't scale when changing the browser's font size option.

Modern browsers (and even the not-so-modern IE7) all changed the default scaling method to simply zooming in on everything, including images and box sizes. Essentially, they make the reference pixel larger or smaller.

Yes, someone could still change their browser default stylesheet to tweak the default font size (the equivalent of the old-style font size option), but that's a very esoteric way of going about it and I'd wager nobody¹ does it. (In Chrome, it's buried under the advanced settings, Web content, Font Sizes. In IE9, it's even more hidden. You have to press Alt, and go to View, Text Size.) It's much easier to just select the Zoom option in the browser's main menu (or use Ctrl++/-/mouse wheel).

^{1 - within statistical error, naturally}

If we assume most users scale pages using the zoom option, I find relative units mostly irrelevant. It's much easier to develop your page when everything is specified in the same unit (images are all dealt with in pixels), and you don't have to worry about compounding. ("I was told there would be no math" – there's dealing with having to calculate what 1.5em actually works out to.)

One other potential problem of using only relative units for font sizes is that user-resized fonts may break assumptions your layout makes. For example, this might lead to text getting clipped or running too long. If you use absolute units, you don't have to worry about unexpected font sizes from breaking your layout.

So my answer is use pixel units. I use px for everything. Of course, your situation may vary, and if you must support IE6 (may the gods of the RFCs have mercy on you), you'll have to use ems anyway.

workaround for browser font sizing (using rem)

Actually you should not use rem for border size in my opinion (except for some rare cases maybe). Specially if you want to have a hair-line border then use 1px. There is nothing wrong with using pixels where they actually make sense.

We have used rem's with pixel fallback in large scale web projects but never used rem for the border sizes (but we have only used hair-line borders most of the cases). In my opinion units relative to font (rem, em, ch) should be used for content relevant elements such as font-sizes and negative space between content elements using padding / margin.

Sometimes even rem's are not the nicest solution. They are great because they are predictable in comparison to em's but you also loose a lot of dynamics. Recently we were following an idea by Chris Coyier to set a font-size in rem on component level (article, product teaser etc.) and then use em on sub-elements of the component. This gives you the flexibility to change the rem font-size on component level to scale the whole component content.

How to make Compass Vertical Rhythm output Rems instead of Ems with px fallback?

For the moment, these updates to Compass remain in the pre-release gem, and the matching documentation isn’t yet available on compass-style.org (not even beta.compass-style.org). To use the new features, install the latest gem (0.13.alpha.4):

gem install compass --pre

With the new gem, the vertical rhythm API is slightly different, mostly in its configurable variables, as per https://github.com/chriseppstein/compass/pull/896. In short, set your base font size and line height, and set the new $rhythm-unit variable to rem:

$base-font-size: 16px;
$base-line-height: 24px;
$rhythm-unit: 'rem';

The $rhythm-unit variable replaces $font-unit, and $relative-font-sizing is now a private, internal thing you don’t need to worry about.

After this, all the normal vertical rhythm mixins will output rems with fallbacks (unless you explicitly set $rem-with-px-fallback to false). Note that the rest of the API remains nearly identical, with the exception of the rhythm mixin, which now has more sensible default arguments. There are a few additions which are detailed in the original pull request.

One thing to keep in mind that the rhythm functions can’t provide pixel fallbacks, since they simply return a value.

Do REM's at base 10 equate to exact pixel size?

font-size: 62.5%; only sets the font size to 10px on the html element if the browser is set to factory defaults.

If the user has selected a different default font size, then everything will be scaled to match.

Firefox font size preferences

Using Rems with a Pixel Fallback