CSS

R.I.P. REM, Viva CSS Reference Pixel!

The web is full of resources telling you to use the relative lengths “em” and “rem” over pixel, because they would make your design more accessible. Almost all Front-End Developers I know (including myself) were blindly following these instructions for years and it became a de facto standard in the industry. I’ve done some research lately that completely changed my mind about these two relative units. I won’t use “rem” going forward and only use “em” in very specific use-cases. In this article I’m going to share my observations and hopefully convince you to put an end to our beloved “rem” unit, that finally made it into our tools without fall backs (given IE8 dying slowly), but became totally useless in favour of the more popular CSS reference pixel.

Gravestone of REM 2005 - 2015

The “em” unit has its origin in typography and it was used as relative size in relation to the font size of a given type. Back in the days, print was all about letterpress typesetting, where letters were stamped onto paper using metallic so called quads (originally quadrat). These quads were all of the same height and could fit every letter of the alphabet for a given size and type. However, they varied in their width, and because the upper case letter “M” was always very close to equal in width and height, the convention to use the width of “M” as relative unit established. Thus the origin of the unit name “em” as it’s just the phonetic representation (ɛm) of the letter “M” (I couldn’t find any historical proof for this derivation, but people seem to agree that this is the most logical explanation).

Computers are all about pixels and when the “em” length was introduced with CSS 1 back in 1996, its main purpose was to bring a unit that’s relative to the font size in a given context. The specification says:

The relative units ’em’ and ‘ex’ are relative to the font size of the element itself. The only exception to this rule in CSS1 is the ‘font-size’ property where ’em’ and ‘ex’ values refer to the font size of the parent element.

In the beginning “em” was a nice addition to CSS and it allowed to build a design that was sensitive to your content. You could size text of sub-elements relative to parent elements or do things like specifying your padding with “em” to ensure you have a larger padding on your text container than your word space (conforming to the visual rule of proximity).

Another use-case, which was the main reason “em” became very popular, was for accessibility reasons. Its nature of being relative to the root of the DOM (while following the constraints mentioned below) made it perfect for resizing your whole design on user preference. Browsers supported to change the default font size which then changed the calculation of “em” units in your whole website.

But there was a rather large downside to “em”. Like outlined in the specification, it it’s inherited and if you have multiple nested elements that override the font size in “em”, you’ll need to go through some math exercises every time you want to calculate the actual font size somewhere deep down in the DOM.

Let’s illustrate this problem quickly by looking at the following code snippets:

<div class="level-1">
  <div class="level-2">
    <div class="level-3">
      <p>Hello!</p>
    </div>
  </div>
</div>
html {
  font-size: 20px;
}

.level-1, .level-2 {
  font-size: 0.5em;
}

.level-3 {
  font-size: 2em;
}

What’s your take on the font size of the text “Hello”? As the “em” value changes with the cascade and nesting of the DOM, it’s really hard to keep track what’s going on. The text in this example would be 10px in size as the initial 20px on the html element is multiplied by 0.5 two times before it’s multiplied with 2 again.

REM, the Super Hero of the Units!

Finally with CSS3 there was a solution to the above problems. REM stands for “Root EM” and literally refers to the “em” size of the root element. The root element being your html element in the context of web documents.

This was simply fantastic! We could use relative font sizes for accessibility but still avoid the mess of having a nested “em” structure. Almost every developer adopted this new and fancy CSS length unit and it became very popular.

The only problem with it was missing IE8 support. Since the second draft of CSS3 in 2005, REM was not considered to be important enough to be included in the 4 years later released IE8. Anyway, as we know how to work around IE issues, we started to use the REM with pixel fallback pattern.

.my-text {
  font-size: 32px;
  font-size: 2rem;
}

Gentle, how CSS is, it was always built on the concept of graceful degradation. If the rendering engine does not understand a property or value, it simply ignores it. That led to modern browsers favouring the “rem” bit over the property specified above with “px” and older browsers just ignoring the later line specified with “rem”.

The Mobile Age

We are living in a mobile age today and this changed the internet from both ends, how we consume it and also how we build it. Responsive web design became very popular and probably the most used buzzword ever. While already specified in 2010 by Håkon Wium Lie, the media query module entered the CSS3 specification relatively late in the working draft 8 which was the last call working draft at the same time.

Media queries are an asset every front-end engineer is aware of today and we use them almost on every project to some extent. When they became popular and people started to design their web sites for mobile devices it didn’t take long until some debates started whether to use pixel or relative font units “rem” or “em” to specify media queries. Let’s take a look at Zurb’s responsive CSS framework Foundation 2 that was released in October 2011:

/* Mobile */
@media only screen and (max-width: 767px) {}
/* Modernizr-enabled tablet targeting */
@media only screen and (max-width: 1280px) and (min-width: 768px) {}

You can see that in this desktop first approach everything between 768px and 1280px was considered a tablet (with a modernizer enabled touch selector) and everything below 768px was considered a mobile (phone).

What you can observe as well, is that pixel units were used to specify the media queries. Let’s take a look at a more modern version of Foundation. Foundation 5 was built mobile first and uses “em” based media queries for all screen sizes.

/* xs up */
@media only screen {}
/* small up */
@media only screen and (min-width: 40.063em) {}
/* medium up */
@media only screen and (min-width: 64.063em) {}
/* large up */
@media only screen and (min-width: 90.063em) {}
/* xlarge up */
@media only screen and (min-width: 120.063em) {}

If we assume the browser default font size is set to 16px and calculate our “em” based on this then those media queries would be computed to 640px, 1024px, 1440px and 1920px.

At first glance this makes a lot of sense since now we have media queries that are based off the root element font size, which means our media queries scale with the browser font. However, there are plenty of issues with using “em” or “rem” in media queries as you will see in the conclusion section.

The Raise of High DPI

A few years ago pixels on screens were very clumsy large squares you could easily spot an arm length away from your 17’’ monitor that was running on XGA (1024×768) resolution. With increasing screen resolutions and the harmonization that came with HD video, it’s not only about resolution anymore. It’s clear that user interfaces on very large resolutions get hard to handle as the objects on the screen get very tiny.

In order to cope with this problem, operating systems and software user interfaces introduced a scale factor (in web development referred as device pixel ratio) that will actually be used to calculate a virtual pixel in the software. You can imagine that the user interface is actually rendered larger as it would be normally. Most of the modern smart phones today have a device pixel ratio of at least 2 which actually means that they are not 320px in physical width but 640px. Still, the operating system on your phone knows that it needs to render every element twice as large to compensate your viewing. Terms like physical pixel or device resolution refer to the real amount of pixel that are available on the device while the virtual size is often referred as logical resolution.

In CSS this problem was actually already addressed in version 1.0 back in 1996. The following quote from the W3C specification of CSS1 describes the CSS reference pixel angle.

Pixel units, as used in the last rule, are relative to the resolution of the canvas, i.e. most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the UA should rescale pixel values. The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is about 0.0227 degrees.

This is the second time I was surprised about the technical vision the guys at Opera already had in mind when specifying CSS1. My first surprise was the vision about media queries they already noted down in the specification about @media in CSS1.

Future versions of HTML may introduce new values and may allow parameterized values. To facilitate the introduction of these extensions, conforming user agents must be able to parse the media attribute value as follow:
The value is a comma-separated list of entries. For example,
media=”screen, 3d-glasses, print and resolution > 90dpi”

This was 1996 guys! They probably met “Doc” Brown from “Back to the Future” and he told them about Oculus Rift…

So that’s great then! We have operating systems that can scale user interfaces and we have the web that can scale web site content with the use of the reference pixel. Why am I telling you all this!?

The truth about accessibility and todays browsers

In order to understand the need for the “rem” unit we need to go back in time a bit. By back in time I mean that time when desktop screen resolutions were roughly 1024 pixel in width and our preferred browser was IE6. Hand in hand our preferred web font was Tahoma or Verdana with a size of 10px. No joke that was state of the art, if you didn’t happen to have the chance to enjoy this!

At that time the most common way to enhance accessibility for poor-sighted people was to scale your web sites text size. In IE6 you could go to your view settings and from there you could change your text size from normal to large or extra-large. This had a direct effect on your browser default font size (which was 12pt in IE6) that is inherited to the html element. Back then we have used “em” to style our content so if a person with disabilities was changing the default font size, they got the whole website scaled instantly.

However, that was 2001. Devices have evolved and so have browsers and operating systems.

At the time when the “rem” unit arrived to fix the problems discovered with “em”, it also became irrelevant because now we have a widely adopted reference pixel that is easily controllable by the user. The new magic technique is simple zooming. In version 7 of internet explorer that was released in October 2006 there was a very prominent zoom icon on the bottom right of the browser window. And guess what… The zoom function was just modifying the CSS reference pixel in the browsers CSS rendering engine! What a breakthrough! And to give you the full picture I’ve put together a screenshot gallery from old browser versions with some annotations on how they handle this specific accessibility issue.

IE6 Screenshot showing font size configuration
IE6 (2001) only allows text zoom (changing browser default of root element font size) and therefore was a browser where “rem” would have made sense and “em” definitely made sense
zoom-ie8
IE7 (2006) and IE8 promoted zoom on main UI that changed the reference pxiel, text zoom was possible in view menu
zoom-ie9-ie11
IE9 (2011) – IE11, zoom and text size change both in view menu where zoom is clearly more promoted as it shows the current zoom level and is above text size change
zoom-safari4
Safari 4 (2009), Zoom in view menu and less promoted text size change
zoom-firefox3
Firefox 3 (2008), default was zoom, text size change not so intuitive in menu
zoom-chrome14
Chrome 14 (2011), default was zoom, text size change very hidden in settings

As you can see, even Stone Age browsers don’t promote user agent default font size change anymore. They promote the zooming function (CSS reference pixel) over the text size change. And this makes absolute sense. If you change the reference pixel size, you change the entire design, making everything larger and not only lengths that were specified with “rem” or “em”.

An other fact that plays into accessibility are the system wide settings that get reflected down to applications. A person with disabilities will most likely change his operating system accessibility settings permanently. In Windows, a user can change his DPI scaling settings to something above 100%, which is very similar to the CSS reference pixel in the browser. It will cause the operating system to scale object and user interfaces where possible. It also notifies applications about the increased DPI scale factor. And guess what? The browsers will use this DPI scale factor to influence the CSS reference pixel, so it appear that there is a default zoom applied in the browser. This is one reason more why the “rem” unit is mistakenly praised to be an accessibility hero!

Conclusion

If you are still using “rem” or “em” for accessibility purpose, stop using them immediately! They are completely counter intuitive and just introduce another level of abstraction that is no longer needed. You’re never sure what the root element font-size is and you need to do math in order to get something you can relate to (pixel).

Our minds are trained in pixel and that’s how we process images and work with user interfaces. We are soon living in a DPI independent world where virtual pixels and logical screen resolutions will be everything we need to be concerned about and for the web this is true since 2006 (even earlier if browsers would have adopted earlier)!

So please do yourself a favour and trash your “rem” lengths and use pixel instead! The best practice today, which is also obvious due to the promotion and placement of today’s browser user interfaces, is to use the zoom function if you are visually impaired. This will change the CSS reference pixel and the whole page will be zoomed including your pixel length, “em”, “rem” and everything else too.

As far as “rem” or “em” in media queries go, I’m completely against this and found it even more counter intuitive. The problem there is that “rem” as well as “em” don’t refer to the root element (html) but to the browser defaults directly which can only be changed using the browser settings for base font size (which in modern browsers, is hidden in the advanced settings). This means that even if you specify a font size of 30px on your html element, media queries will still use 16px as “em” / “rem” based for the media queries unless you also change your default font size in the browser settings.

It’s also important to know that when zooming into a page and modifying the CSS reference pixel, the media queries specified in pixel will also use the reference pixel to compute the actual amount of pixels. This is not the case if you use device-width in your CSS media queries, which refers to the physical pixel without taking CSS reference pixel into account. However, I see no valid reason where device-width should be used instead of width (or min-width / max-width).

In order to experiment a bit and do cross browser sanity checks I’ve created this simple test page on JSBin. As you can see when zooming in, the media queries in pixel behave the same way as “rem” based media queries.

There are some very specific use cases where the use of “em” actually still makes sense. If you’d like to use a relative length to a components font size, from a visual standpoint, then “em” makes absolute sense. But for “rem” I can’t find one valid use case anymore. If you can prove that I’m wrong I’d be more than happy to hear your opinion.

Standard

61 thoughts on “R.I.P. REM, Viva CSS Reference Pixel!

  1. Curtis says:

    I think rem can still be useful for font sizing.
    ie: if you want to scale up/down a bit for desktop/mobile, it’s far easier to change a single value than it is to override every instance of font-size: *px;

    Like

    • Hi Curtis! Yes, I agree with you. There are technical use-cases where you’d wan’t to “em” for. However, I believe for cases where you wan’t to scale your whole font landscape, “rem” is not so important. In most cases you don’t want to scale all your fonts linearly anyway. You probably want to make your body text larger but then scale your headings down a bit because they are way too large on mobile. At least that’s my experience, and for those cases, overriding individual parts directly and using CSS pre-processing for variables does a perfect job already.

      Liked by 2 people

    • I thought so to and I’ve tried that. I tried redesigning my blog using rem and realized that scaling all text proportionally is not optimal for readability and the design. You need to tweak headlines and body text separate for all viewports for an optimal result.

      Like

  2. Personally I still think rem or em has a place in styling. Let me illustrate with an example.

    For instance I use em and rem based values only if my layout is related to the font-size of the text. An obvious one would be line height (ussually around 1.5em), but also margins of paragraphs or the height of an text input field
    When it comes to border width, for instance, I do prefer pixel widths, because that has a tendency to look more consistent across devices and browsers/hybrid apps.

    Like

    • Hi Sanne!

      As far as line-height goes you should probably consider to use unitless values (like 1.5) as they will act as a multiplier of the current elements font-size rather than resolving to a computed value that is inherited. Check https://css-tricks.com/almanac/properties/l/line-height/

      I agree with you that, from a technical view, it makes a lot of sens to use “em” for visual elements in your design, if they are directly related to the content text size. My example in the article was about a padding with “em” that can be specified so that no matter what the text size will be, the padding will always be a multiple of it. However, this is all about visual design elements that are nested in a holistic design. “em” makes complete sense for this but I’d think “rem” and specially used for accessibility can be neglected going forward.

      Like

  3. Pingback: Tweet Parade (no.14-2015) - Best Articles of Last Week | gonzoblog

  4. Nadya says:

    PX doesn’t respect user settings and should therefore be considered harmful.
    The USER knows what they want more than YOU do.

    What is the font size of the H2 in the following examples?

    User has not changed browser default font size of 16:
    body { font-size: 100%; }
    h2 { font-size: 18px; }

    User has changed browser default font size to 20:
    body { font-size: 100%; }
    h2 { font-size: 1.1em; }

    User has changed browser default font size to 12:
    body { font-size: 100%; }
    h2 { font-size: 1.1em; }

    “rem” has never had a valid use other than to simplify the math behind using “em”. It’s built out of laziness. But “em” should be used over “px” in a content-first design.

    Liked by 1 person

    • Hi Nadya

      This whole post is not about “rem” or “em” are bad and pixels are great 🙂 What I wanted to show is that the user preference to scale the text size only is going away in the future and even today is a very rare use case. In accessibility there are still two use cases I guess. One would be to increase text size for readability and the other one would be to zoom into a specific region to see all visual aspects (not only text) of this are. However, if you think about it carefully and do some testing, the first use case is no longer needed with Responsive Web Design. Just do a test and zoom into a responsive web site. It’s the best thing you can do. The content will be perfectly presented. Large icons, large text and images. Clear design that is focused on content. I think the separation of text zoom only and magnification / zoom still exists today because on non-responsive designs you’d need to do some crazy side scrolling actions in order to reach some content, but with RWD this issue does not exist. Think about it.

      Also shown in this article is that the text zoom feature is moving away slowly. It’s not as promoted as the regular zoom. Also speaking about user preferences. If you change your preference in Microsoft Windows to scale the user interface of the Operating System, all applications including your Browser will receive this DPI scale information and will apply a default Zoom which is magnification and not text zoom. I really think we should re-validate our knowledge and also do some research with accessibility groups again because things have changed.

      Cheers
      Gion

      Like

  5. john says:

    “What I wanted to show is that the user preference to scale the text size only is going away in the future and even today is a very rare use case.”

    Sir, you may take a look at ebooks, which formats were designed about the very idea of text-sizing only. And since those formats are borrowing web standards, the very rare use case is actually not. Millions offshore people rare scaling the text size only each day.

    Liked by 1 person

    • Hi John

      I actually never thought about ebook readers :-/ and I’m not familiar with how they work. My research was focused on web browsers only. That’s a very fair point! I’ll try to research more into this direction.

      Like

    • Marko says:

      To be honest, eReaders are basically like a smartphone, but without JavaScript support. To target them specifically more than just using `em` is needed. I know not of many people who’d use them for browsing web, as that’s not their purpose and hence thinking of them as a valid case is not something I’d do.

      There’s pocket and similar services which address readers specifically. Most readers even don’t have web browser. So this is not a valid point, unless you’re designing something like epub.

      Like

  6. @nichtsistwahr says:

    The zoom functionality (as opposed to modifying the font size) has been so successful because once internet connections got faster, web developers started using more images and thus switched to fixed, pixel-based layouts. Those layouts would neither adapt to different screen sizes nor user defined font sizes, so the browser vendors adapted and started to offer a layout zoom that would not break the layout.

    But: zoom functionality (and changing ppi) has its drawbacks, because on screens that aren’t in the 24+ inch range it will often cause text flowing beyond the viewport (at least for non-responsive layouts). That makes an awful user experience.

    Altering ppi settings and/or zoom will potentially mean blurry graphics as well (if they aren’t vector based). This would probably not pose a problem for people that aren’t able to perceive that level of detail. But limited eyesight is not the only possible motivation for wanting larger text. Maybe the user simply likes larger text (who are we to judge?). Maybe the user has dyslexia and needs larger font sizes. Or even a different font, that might have a different x-height (which might be a good use case for ex or ch). This certainly wouldn’t be typical, but it isn’t uncommon either that people will use browser extensions to change the way websites and applications look and behave. Pixels / ppi cannot always adapt to that very well, it’s all-or-nothing.

    Blurry graphics and viewport problems will probably vanish over time (thanks to vector graphics and responsive layouts), and you can achieve the same behaviour using em or pixels. So in the long run, the two main questions are:

    Should the user be allowed to change the font size independently of graphics?
    And if so, where should that happen?

    Those are design choices, and I don’t think you can easily dismiss the need for layout independent font sizes on principle (see John’s comment on ebook readers for example). Especially for websites and web applications that are text-centered, there can be good arguments for allowing the user to change the defaults. If the user chooses to do so, it is very likely that she or he will want to do this globally and not on a site-to-site basis.

    So to sum up: It should be an active design choice whether you want to enable users to change the font size independently to parts of or all layout and graphics. If so, pixels will probably not be your friend. If not, I’d say it’s mainly a matter of personal taste and/or project.

    Liked by 1 person

  7. Although it’s true that the CSS pixel is not a physical pixel and thus not as bad for responsive design as generally thought, you cannot simply ignore the “base text size” that users might want to assign in the browser settings. Yes, it’s not as popular as its “zoom page” counterpart, but those people who rely on changing the base text size do need it for real!

    I keep on using em but always try to avoid the nesting situation, which is not that much of a problem.

    Like

  8. brandonbrule says:

    This is a really interesting article, and clearly well thought out.

    I agree with you is that managing both REM/PX is counter intuitive and more difficult to manage, but I’m not sure I have a full understanding of how many devices/browser vendors would be affected by not using relative units of measurement.

    My understanding is that the best case scenario for this approach would be to code using PX and use a CSS post processor to do the REM conversions and fallback for you. PX in development, REM/PX for production.

    https://github.com/robwierzbowski/node-pixrem

    Node may not always be available, so this may not work for everyone but there are two major benefits to this.

    No longer need REM? Turn off the conversion module.
    Work only with PX in your CSS file.

    Another approach to this would be to use a CSS preprocessor like SASS or LESS Mixin/function to handle these conversions for you. I’ve tried a bunch of these with varying degrees of success. I use guss-rem by the web team for the guardian. It’s by far the best REM Conversion mixin.

    https://github.com/guardian/guss-rem

    It’s good because the majority of css properties can be declared as px, but it would be a little bit more work to remove the mixin from a project then a post processor.

    I don’t think I could remove them from my projects because I know that even though the market share of browsers that can’t handle this is small, it’s still a possibility that exists.

    Great article, lots to think about.

    Like

  9. Pingback: Weekly News for Designers (N.280)

  10. For years at a previous agency I worked for (many moons ago now) we consistently used em’s for font-size and set a font-size percentage on the body which would deliver a near consistent em to pixel ratio, for example 1.6em would be very close to 16px consistently. This made life easier when constructing media queries as we could simply change the percentage font-size value on the body in our css as smaller sizes to scale all of our fonts… The down fall to this method though was in nested elements where a font-size was cascaded down and a specific em value would then be smaller or larger based on what it was inheriting, which with the messier developers could make life hell in keeping things consistent. In summary I think every project should be approached as an individual and the most appropriate solutions implemented.

    Liked by 1 person

  11. Pixel unit doesn’t respect user default settings. Dealing with em is maybe not as simple as px, but it respects user preferences. MQ in em also show the best content while respecting user preferences.

    It is NOT up to you to decide how user zoom (with text-zoom or global zoom) or to say “they are zooming this way”.

    The real challenge is to offer a way that is the most compatible with all the variety of users (browsers, default settings, device, etc.), even it is less confortable for developers.

    Saying this kind of things “If you are still using “rem” or “em” for accessibility purpose, stop using them immediately!” is NOT responsible.

    Like

  12. Pingback: Revision 215: Einheitsbrei | Working Draft

  13. I made many researches on this subject by my own. And I came to the exact same conclusions as you. Just saying.

    What appears clear to me now as I read the comments, is how it’s difficult to hold an opinion against the common web development DOGMA (one among many.)

    People don’t like to reconsider their beliefs and thus become quickly emotional or aggressive to those who challenge them.

    Conclusions :
    – No useful use case of REM anymore => Trash.
    – Browsers are addressing accessibility by their own means : they can’t just afford to rely on web developper always-changing best practices to handle that. Moreover even if those practices where clearly defined, not everyone that makes websites is even aware of these practices, and just do on-the-fly prompt edit with pixels or whatever they found good to use in the moment. So yes Browsers vendors are pushing their zoom function to the front, and don’t need us for that.
    – EMs are good in some particular use case, which you already covered in your article.
    – And for the rest : PIXEL RULES. Because, again :
    1. Desktops’ zooms work fine, and mobiles also allow the same type of zooming with fingers.
    2. When you change font size in modern mobile OS settings, neither rem nor pixel sized element within chrome is affected. And when this time you change chrome’s font size, only fonts are affected, and the EXACT same way, whether they’re in REM or PIXELS. For all other sizings that are not fonts, or that are fonts but within a sized container (in any unit, pixel, rem or whatever) : chrome’s size settings has no effect. All of those sizes remain unaffected and the root size still rules (just tested with Android 5.1.1).

    So Browsers Vendors don’t give a shit about your EM/REMS-based “take-the-users’-preference-into-account” theory and seem not to be planing to rely on that to make the web robust and address accessibility.

    Liked by 1 person

  14. Pingback: フォントの単位はどれが適切?Pixel?EM?REM?

  15. Haha, intersting.
    I’m a Pixellover and use it for all. I’m not a fan of EM / REM and so on.
    But today I start with a new project and I’m currently on the projectsetup and thought I use this time REM to give it a try.

    After short google action I come across you article here and now I must laughing… 🙂
    I stay with my PX, thanks 😀

    Like

  16. Pingback: Sass — Responsive Font Size - David Hellmann — Designer. Developer. Cyclist. — @davidhellmann

  17. “If you change the reference pixel size, you change the entire design, making everything larger and not only lengths that were specified with “rem” or “em”.”

    One thing I wonder is: isn’t it common practice to define div’s and structure’s size in ems and rems too already? I mean you says that if we specify everything in pixel and the user changes his base pixel setting and stuff like that everything scales…but that holds true even if you specify a base px size for the html/body and then scale everything off that using ems/rems for font-sizes and the structure right?

    Maybe I’m missing something.

    Like

    • quasiDigi says:

      My opion too.
      REM still has a lot of life and advantages over pixels.
      One of the most obvious benefits is to have everything in proportion with each other based on an abstract unit. As the unit is abstract it is easy to scale dynamically (for example with js or in media queries)

      Like

  18. i agree totally with you! i did some research too and i also used foundation for a project and i wont use it ever again. foundation says its doing mobile first but they mean doing “tablets” first. people use smartphones and pc/laptops more often than tablets. it was such a mess with calculations and especially horror for smartphones. i wont the phones browser to decide what MY page should like, I AM the designer and its up to me. REM / EM is just supporting laziness and brainfuck.

    Like

  19. davidg707 says:

    I’ve been using rems for sizing recently because setting px is saying to the user “no, you may not change the font size”, but I have no idea how many users this affects.

    It seems like the whole argument centers around guesses about how many people use text zooming. Does anyone have any data?

    Like

  20. They calculate in PX anyway… says:

    Funny observation from the coding front: internally, all browsers and screen readers will calculate a “pixel” from EM, REM, et al. Guess all those anti-PX people forgot they’re just scripting a display thingy which works with bits and bytes. 😉

    Like

  21. Check out https://sassline.com … rems are very, very handy. Yes, it’s a lot of math (and trying to get your text to align to a baseline grid is not only a LOT of math, it’s a lot of headache), but the result is quite nice.

    Then, if you size your images in rems, they will align to this baseline grid too. In my opinion this is a huge win for design.

    That said, Sassline uses modular-scale and you are right — it’s sometimes annoying (and anti-design) to have a limited range of sizes that are all spaced out in a linear fashion. You sometimes want something in between. The problem is that then breaks the baseline.

    Sure enough, good design can break the grid when necessary and appropriate. So there’s a downside, but I also think rems provide a great value with regard to type that should not be cast off so quickly. Though I’d LOVE an alternative solution.

    Like

  22. Thank You for this article! Now I can finnaly CLEARLY see difference between px and em values. After reading I think the best solution is to use em values only for text and leave rest in px (unless em is actually needed for something).

    There are users who change their base font-size, not just zooming. Then I think we should respect their preferences. The downside of this approach is for sure possibility of breaking layout if text is longer. But as long as you keep it in mind, there shouldn’t be any problems 😉
    Cheers, and thanks again!

    Like

  23. Rob Schlüter says:

    To me rems are bad for another reason. Pages with rem-based font sizes do not allow normal zoom handling in Firefox.
    In your JSbin example when I zoom down the text above the upper cannot be made smaller at some point where the second header keeps reducing in size.

    Like

  24. I think there is a lot of content missing between the historical background and the “Conclusion”. Listing disadvantages of ems doesn’t directly make a case for pixels. I think that’s missing here. What about the disadvantages of pixels? Gotta say I got little from this.

    I’m coming from a pixel habit and am now considering going with ems. In this day, it’s becoming virtually impossible to identify a mobile device by resolution. Media queries like min-width:1280px no longer work, since some mobile devices have higher resolutions than some desktop monitors and don’t report resolution reliably.

    It makes a lot of intuitive sense to me to switch to ems. I don’t care about screen sizes after all. I care about fitting my content. I know that my button is proportionally the width of my headline. With all fonts and widths set in relative terms (% & em), I can change the base font and the whole thing scales up and down proportionally. I can then target my media query to detect when that content no longer fits regardless of actual pixel width. When everything is set in px, media queries become a nightmare. Half the time, I just want to copy the entire stylesheet into the media query, because I’ll probably end up adjusting all of it. And then copy that for each breakpoint (not every design vision is fluid).

    Still experimenting and learning about ems, but so far I do see good reasons to use ems. One workaround I’m considering is wrapping elements and setting the font-size on the wrapper, so that the em width value of the parent still points at the base font. Maybe ems will end up impracticable also, but for me anyway pixels come with their own problems.

    Like

    • Hi Vlad, I agree there is a lot of content missing and if I’d have time I’d really like to write a follow up covering some of those gaps. I fully agree with your opinion on media queries and we should consider content to write media queries and not display sizes. However, maybe I’m ignorant here, but I believe we should stop thinking that text is the main content within websites today. We’re conveying more information using visual design, graphical content, illustrations, photos and user interface elements. Don’t get me wrong, text is extremely important but I just don’t think it’s more important than all other content elements on todays websites.

      The point I wanted to make here is that I believe text zoom became irrelevant with responsive design. Back in the days we needed to provide text zoom because using reference pixel zoom would lead to a very bad experience. Without RWD, reference pixel zoom would just zoom you in on both dimensions, horizontally and vertically, and you’d need to scroll and pan through the website. However, when your website is implementing RWD nicely, reference pixel zoom is a fantastic experience. The zooming will magnify all content elements on your site, including images, illustrations and all important things. I don’t see any reason for someone who is visually impaired, only wanting to experience the text of your website if there’s a way he can get optimized content and layout for his preferred level of magnification.

      Now you could go ahead an express every single length of your content elements within your website in EM’s or REM’s. Image width, layout grid and other elements. You can also write your media queries using EM’s and finally you have a design that scales well on text zoom as well as on reference pixel zoom. However, I’d never go down this road and trying to think my whole website through relative to my base font size. It just doesn’t make sense for me and there are a lot of issues with this approach too.

      Instead, if I focus only on reference pixel zoom and sophisticated RWD, I can provide a great experience to anyone who needs to magnify my website. Operating systems also increase DPI for visually impaired people which in fact is increasing the reference pixel angle.

      Thinking in those terms, combined with the flexibility provided by CSS pre-processors like Sass, LESS or Stylus, I don’t see any reason to use REM in my design. By sticking to a CSS writing style with the goal to eliminate all DOM related dependencies, I’d anyway prefer to generate redundant CSS and keep my flexibility within the pre-processor.

      I tried to hold a lightning talk about this at FEC but I was not really well prepared and I still struggle to convey the key message here as I simply don’t find any time to think about this more at the moment. You can find the slides here however: http://oddeven.slides.com/oddeven/rip-rem-viva-css-reference-pixel#/

      Like

  25. Pingback: davnn comments on "REM vs. EM – The Great Debate"

  26. I have a different use case for REMs. I have a webapp with highly interactive UI. Initially every element was sized via pixels. But 100 css pixels on a retina display will generally look smaller than 100 css pixels on non-retinas.
    As I don’t need UI elements to be bigger (physically) on non retina screens, I converted everything to REMs and scale them down depending on the screen density (to avoid the manual converting work, I wrote a python script to go through all my style files and replace px with /20 + ‘rem’).
    If there was a way to scale the reference pixel, I’d use it, but “zoom” or “transform: scale” does not work as smoothly as REMs do.
    I could have of course written bunch of media queries to size each of my UI elements, but it’s much more of a hassle than adding a few lines of font-size on the top.

    Does anyone have a better suggestion for what I could have used instead of my current approach?

    Like

    • But 100 css pixels on a retina display will generally look smaller than 100 css pixels on non-retinas.

      I don’t think that’s the case and I’m surprised you’ve experienced that issue. The CSS reference Pixel does exist exactly because of your issue. On high DPI screens, let’s say 4x, 1 CSS pixel would be equivalent to 4 physical pixels. That means your UI is automatically “zoomed-in” 4 times. Or put differently, your UI is rendered four times as large.

      Depending on the device you may have missed to add the correct viewport meta tag?


      <meta name="viewport" content="width=device-width">

      Like

  27. I thought it should be the same but empirically testing, it appears not to be the same height. I.e. when I open the page on a retina display and then on a non retina display those 100px (better actually choose bigger size to see the difference) will be different on both. The difference is not huge, but it is there.
    Check out this fiddle https://jsfiddle.net/qq6754se/1/
    I measured the height of red rectangle on two different laptops and I got different results (as noted in comments in css).

    If I think about it – the inconsistency kind of makes sense – it depends on ppi. Imagine we have an 15″ display with max resolution of 1024×768 and then we have a bigger, old 17″ display with the same max resolution. The physical size of 100px would be different when looking on each of them.

    Now, I don’t know whether it happens so always that retina displays produce smaller physical size for css pixels than non retinas, it’s just what I’ve seen so far. It should depend on actual physical size of the retina display (i.e. the ppi of the device).

    Like

  28. OK, I checked the following – my Toshiba Sattelite has ppi 100 while my macbook pro has ppi 220. Therefore, if we divide 220 by 2 to get “non-retina ppi”, macbook still has 110 while toshiba 100. Therefore the pixel sizes on toshiba will be 10% bigger physically.
    BTW if we’d look at the same page on iPhone (lets say iPhone 3GS since it’s non retina), the pixel size would be even smaller because iPhone 3GS ppi is 165.

    So if I want the UI to be the same physical size, I need to scale it all up or down depending on actual device ppi.

    Like

  29. Pingback: Constructing Fictions, Part 1: Typography – Uebyn's Blog

  30. Pages using rem’s prohibit Firefox from resizing. The result is that I get pages with HUGE fonts which I cannot zoom to a normal level.

    About the use of em being difficult on nested elements. As I see it that difficulty comes from the designer not working in relative sizes. Instead it is attempted to set em values to specific values so that the result is a calculated pixel size. But it’s not about sizes in pixels.

    I find that inheriting the values makes it easier to scale complete parts. That is because I use em values to specify how much smaller or larger a nested element should be. For flexible layouts the resulting pixel sizes are not relevant since a browser has a default font size more or less picked by the user.

    The result is that all texts elements are scaled relative to each other, but the actual pixels sizes do not matter.

    Media queries also work with em’s so you can adjust your layout based on them.

    Like

  31. Michael says:

    Hi,

    Thank you for this article. After trying to use em and rem in many projects, I now use only pixels. One of the main argument for using em has always been “change one value and everything will change accordingly”.

    While this is beautiful in theory, I’ve NEVER encountered a use case where this holds true. When I see the last design my designer did, on desktop I could find a heading at 28px, a small text at 12px, and a price at 22px. On mobile, I have the small text staying at 12px, the heading lowing done to 24px, and the price to 22px. This is just an example but I’ve never stumble across a situation where an element is “20% smaller” on mobile. At the end, I still need to target each element individually, so why bother with a complex math when I could go easier with pixels?

    Of course, maybe the problem lies into my designer who does not reduce everything by the same factor… =)

    Like

  32. Regarding the origins of ’em’, it was based solely on the width of an M. The height wouldn’t mean much because a uppercase M was the same height as every other uppercase letter. Ditto for lowercase.

    Other units and practices were used to deal with height. For example, the relationship between ascenders (like f) and descenders (like g) is important. A tall ascender and shallow descender is treated differently than vice versa. In CSS, it’s all been boiled down to the line-height property, which works just fine.

    Like

  33. Adrian says:

    Google Recommendations:

    WE RECOMMEND DEFINING YOUR FONT SIZE USING PIXELS.

    A pixel can always be thought to change size according to the device it is being displayed on. When displayed on a mobile phone, devices anchor with what is known as the “reference pixel”. 1 CSS pixel is defined according to this reference pixel, and all other units – inches, centimeters, etc – are adjusted relative to the CSS pixel.

    Each font has its own characteristics: size, spacing, and so on. By default, the browser will display each font at 16px (CSS pixels). This is a good default for most cases, but may need to be adjusted for a specific font – i.e. the default size can be set lower or higher to accommodate for the different properties of the font. Then, once the default size is set, larger and smaller fonts SHOULD BE DEFINED relative to the default size USING PIXELS. These can then be used to adjust size of the text for primary, secondary, and other type of content on the page.

    For example, the following CSS snippet defines a baseline font size of 16 CSS pixels, with CSS class ‘small’ that has a font size of 75% the baseline font (12 CSS pixels), and CSS class ‘large’ that has a font size of 125% the baseline font (20 CSS pixels):

    body {
    font-size: 16px;
    }

    .small {
    font-size: 12px; /* 75% of the baseline */
    }

    .large {
    font-size: 20px; /* 125% of the baseline */
    }

    Source: https://developers.google.com/speed/docs/insights/UseLegibleFontSizes

    Like

  34. Pingback: Designing Fictions, Part 1: Typography – Uebyn's Blog

  35. good article, thanks!
    my 2 cents:
    1- To know the real pixel size is impossible,
    Since CSS Pixel IS an abstraction that is different from device to device (and OS) because it changes depending of Hardware Pixel (screen resolution) and Reference Pixel (screen size vs resolution = dpi) ((not clear for me if this calc is adjusted by the Browser or the OS), plus the user preferences (on OS and/or Browser settings)

    You can call it px, pt or shoes, anyway is not really that real static thing but something relative to a lot of conditions.
    Theorically -if device/os/browser vendors do it right, it on calculations , it will always referencing doesn’t matters the unit you choose
    said that:

    2- Text zooming is not obsolete (my Firefox/windows does it on first menu and ctrl + / ctrl – , usefull to adapt hard web sites so my eye is comfortable- so EM and REM becomes important.

    If you born today … will you think on pixels?

    Like

  36. Boyan says:

    From a typography point of view, em and rem still make sense. You can easily set headings proportional to the base font size, instead of calculating pixels. There are certain ratios that usually work best and when setting font sizes it’s much easier to use the ratios and correct only when needed, rather than go pixel by pixel. This is more the case nowadays, where the design for smaller websites is created “on the fly” , rather than beforehand in photoshop or stg.

    Like

  37. The font size of this page makes it very hard to use. If you used REMs, you could easily make the entire page’s font size small by changing to root or html element.

    Like

  38. REMedy says:

    I disagree. I set my media queries in pixels. All font sizes in rem. All (max) width measurements in rem. But most importantly, to ensure consistency, I set the default base font size to 10px html, body { font-size: 10px; }, so then writing 3.2rem is always equivalent to 32px. It works like a charm. Never encountered any problems with this method.

    Like

  39. Pingback: Device-Based Layout | Distillery | Uncategorized

  40. Michael Conley says:

    Hey Gion, you’re conclusion that users with poor sight only use viewport zoom to address legibility is incorrect when, in fact, this is usually done within the OS/application-level settings. Pixel values in the viewport do not consistently respond to these settings, thus rems must be used.

    Like

    • Hi Michael, I’m sure browsers respond different to DPI settings in the system. Fact is that certain OS / Browser combinations handle this the correct way IMO. System settings are propagating DPI settings to applications, which then respond accordingly. Browser should pre-modify the CSS referencec pixel, which also affects the reference Pixel. DPI is still something new to computers and it got more sophisticated when HiDPI became populare. I think there’s still some work missing from both OS vendors and Browser vendors but I strongly believe in Pixel as relative units and DPI scale as the ultimate accessibility tool. Also this is not concluded yet, this article is built on assumptions which needs further testing and proof. I’m still looking to improve my assumptions, testing and maybe better conclusions with a follow up article, but time’s an issue for me right now.

      Like

  41. Pingback: Device-Based Layout | Distillery | Markup

  42. Code Designer says:

    Code Simple: + or – 100% = 8)
    That way you don’t have dang ’em’ headaches that are ‘REM’ bad… Puns intended – I wished we still used Points (pt) to set CSS Font Sizes, it works just fine in the Graphic Design World.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s