Alex Kessinger tweeted asking if there was a reason to still use EMs instead of PX measurements in mobile. This is an interesting question, but 140 characters isn’t quite enough to explain my thoughts. So here’s an old-fashioned blog post!
Just a quick review: em and percentage (%) units in CSS are relative measurements, whereas px and other measurements are not. What this means is that the resulting size of relative measurements depends on the size of the parent.
The original reason to use EMs instead of PX measurements
As far as I can tell, the original reason why it became a good practice to use EMs was because of page scaling and accessibility reasons. When developers used PX measurements, they found that when the page was scaled (using Ctrl + Scroll Wheel), the parts of the page with fixed PX measurements didn’t scale.
Oh no! So when a user with poor eyesight tried to scale a page to read the text better, it turns out that the text they were interesting in making bigger actually didn’t change size at all!
So is this still the case today? By and large, no. All modern browsers except IE6 will now scale pages correctly, regardless of the type of CSS units used.
From what I’ve heard, there are still many users with disabilities using IE6, but the reason is because they don’t want to upgrade their copy of the screen reader JAWS, which is quite expensive. However, these users obviously aren’t affected by page scaling issues because they are blind.
Maintainability concerns
Even if the original reason to use EMs (above) is no longer valid, I still believe there are good reasons to use them.
One of the main reasons is maintainability. If a page is designed to have one base font size (applied to the Body) and all other font sizes on the page use relative units (EMs or percentages), changing the font sizes later becomes almost trivial. If someone wants to later increase the size of the fonts on their entire page, all they need to do is increase the one base font size.
This might be a bit of an edge case, but the elegance of the solution is too enticing! 
Media queries and mobile
Very closely related to the above point is the subject of media queries. Recently media queries have been somewhat hailed as a panacea for all mobile development. I slightly disagree, but that’s a topic for another post!
The main point here is that people are now using media queries to quickly make mobile-friendly versions of their desktop websites. That’s awesome, there’s no doubt about that.
So what about EMs and PX measurements? Here’s the problem: if a developer coded their webpage in such a way that they used fixed pixel measurements, the amount of CSS required in the mobile media query could be obscenely large. This is because each individual element with pixel measurement was designed with the desktop in mind! This makes the task of adapting to different content very painful.
On the other hand, think about a page designed with relative units such as EMs or percentages. This page was designed so that each element was proportional to its parent element, so that ideally changing the size of the entire page occurs in only a few places, at the Body level of the document. Suddenly the CSS required for the mobile media query is much more manageable, since it’s now (ideally) only changing a few values on the Body element, not on every element on the page.
You alluded to this but I think there is also a notion of em’s and grids. In a vertical grid it might be helpful to use 1 em as the grid unit, and then you can define everything in terms of the grid. So to adjust the grid you need only to adjust the height of the em, which is just adjusting the height of the base font-size.
@Alex I guess I don’t have enough experience with grids, but that does sound quite useful! Definitely sounds more maintainable.
Hi David!
I agree with your argument that EM’s (and EX’s) are still great to use in stylesheets, instead of PX. My approach is a hybrid. I take into consideration the pixel relativity zooming that you correctly say all major browsers support these days, so making layouts “pixel perfect” in PX is a good idea for framing. But for padding, paragraph indentations (yes, some people still appreciate that old fashioned concept which endured for centuries in print!), header margins, and many other uses, EM/EX is better than PX because of one thing: fonts are still the Achilles heel of the world wide web.
Fonts on a Google TV differ from fonts on an iTouch differ from fonts on Windows XP differ from fonts on Windows7. So to keep things proportional to the size of the em/ex which the native platform brings to the web, we MUST use em/ex instead of PX. When sizes & padding of page modules is type proportional, the appearance is so much smoother. Until we have some kind of guarantee of having or sharing identical typefaces across the world wide web, we have this situation where certain measurements need to be in RELATION to dimensions in the font.
Sincere regards,
Monty
Some of my clients are government clients which dictate for accessibility reasons that we must use ems. However now that I’m used to using ems I would never go back to px. It’s a much more elegant solution and as Alex mentioned above, great for vertical rhythm and also horizontal grids.
Whenever I see a CSS sheet using px it strikes me as slightly amateurish, maybe I’m not just snob.
Fascinating, I wasn’t aware of the JAWS upgrade issues. Seems that a proportion of the users we’re worrying about laying things out correctly for in that dinosaur browser aren’t even seeing the result of our efforts…
Well, you are wrong, thinking px as an absolute unit. Not only W3C says it in the specs (look into HTML4-specs) you can find it with pure logic. If you change the resolution on your screen, the dimensions of it remain the same but now more or less pixels fit into the screen. Therefor: a pixel is a relative unit.
We only got used to em, because IE6 doesn’t scale a pixelbased layout if you don’t search deep in the menues of IE6 to make him do so.
I perefer PX!
I’m author of Emastic CSS Framework http://code.google.com/p/emastic/ (like the name indicates it is using em like primary unit) . I want to share some of my experience with em.
In the begging the main reason why someone used em was the text resize issue. Today that issue remains naturally for the older browsers and for the users who are using text resize.
But the beauty of the EM’s is something else the power of controlling all layout with just one parameter (font size). When you are working with ems you have the sensation that you are working with something really powerful. Ems are pixel precise but can be elastic and interact with the browser. Let’s say that the em is power px. The world of ems is yet to be discovered.
I for one cannot stand page zooming. Even with a 27″ monitor. I hate it. I always disable that and choose to go with text resizing instead. And I have used ems for years and will continue to do so. It doesn’t take any more effort than pixels and i just think relative units are more flexible and maintainable.
Well yes, today’s browsers uses zoom rather than enlarging the font size. However, the reason to use EM/pct rather than PX/PT, is due to the browsers default font-size, which is 16px by default, but adjustable, and may be a more preferable method to increase readability.
Also, most mobile browsers will override the font size anyways. This can be prevented on iOS and WinMobile.
html { -webkit-text-size-adjust:none; -ms-text-size-adjust:none; }
This is how I deal wirh this..
I only use pt for when an exact font size is required or if I want to set a baseline definition in the css at the *{}
All my other declararions are percentages except for margins and paddings where I use px
A great topic, but you missed something.
Regarding the accessibility issue, the people I know (my Father being among them) who require the fonts to be bigger will not press CTRL and + every time they load a page on every web site. That is an unusable solution to something that is much easier – and that is they simply specify a larger default font size in the preferences. In Firefox for example it’s in Tools -> Options -> Content -> Fonts and Colours. This way a larger font is displayed on all pages they view.
It’s important to note that this behaviour is much different to the manual zooming method, because while it’s true browsers will scale when zooming manually regardless of if the site was built with EM or PX, the browser preferences option only works when the site uses EM. PX gets ignored and stays whatever size the designer declared in the style sheet. And that happens to be something small, say 11px or even 12px, that might make the site unreadable for them.
That’s enough reason for me to use EM’s. They are just as easy to design with as PX if you follow the 62.5% trick anyway.
http://www.thatwebguyblog.com/post/making_the_transition_from_px_to_em
PS: I notice you use Em – good man
For many years, I have been trying to use each time em rather than px in website that i developped. I totally agree with those who prefer Em for vertical rythmn, for accessibility and for layout reasons. And I think having font resizing method in Firefox is really important.
I tend to vary on my use but after reading all your comments I think its about time to start going all out on em. Thanks for the nudge in the right direction guys.
Whether you use px or em, there is no point of using the same stylesheet for web and mobile. Page size is a very big factor for mobile site hence the design file should be a different and cutdown version to optimize the load time in mobile.
Apart from accessibility, flexibility is the key factor. And while it is possible to use px to build a flexible (widths and heights of elements can change without breaking) design, em’s put a little more pressure on your work.
A more in-depth comparison can be found over here: http://www.onderhond.com/blog/work/px-vs-em-design
I was used to using px and fixed layouts, but recently I also found out about ems and have got addicted to using them….
I have always found myself debating between PX and EM while at the start of a project. Even as the layout progresses I switch between both to see which one works better. In the end I have a mix of PX, EM and % sizes all over the place. I have never been able to stick with one; to me they all work together quite nicely.
So one main argument would maintenability? Right. Instead of using em which is painful to work out, I propose using LESScss. It allows variables so @base-size: 12px; h1{font-size:@base-size + 4px; } would achieve the same result for example.
Just to clarify one point: it’s not just IE 6 that doesn’t allow scaling of pixels. IE 7 and IE 8 also don’t allow text sized in pixels to be resized. IE 8 does allow you to zoom the entire page, but it doesn’t let you scale pixel text. (I haven’t tested text scaling in IE 9 just yet, and I don’t have it on this computer to do a quick check.)
Regardless of IE’s shortcomings, however, I agree that pixel sizing of text is not a good idea. With percentage or em sizing of text, you’re going to be closer to the user’s chosen font size even if you size down from 100%. For instance, let’s say a user has set his browser’s text size to 24 pixels instead of 16. When you use 88% as your web page’s base font size, this user will see text that is 21 pixels instead of 24. While this is not his exact preference, it is a lot closer to it than 14 pixels—the size that 88% translates out to for the majority of visitors who do not change their font size. Setting the font size to 14px instead of 88% would work exactly the same for most visitors, but would be very problematic for the small subset of users who have gone to the trouble to customize their browser to their needs. You can be confident that setting your font size to 88% is the same as setting it to 14px for most users, but when you use 88% instead of 14px, the users who have chosen a different font size still get a size close to their preference. Everyone wins.
EMs are great unless they are being used on a large CMS, where it is difficult to control the HTML structure. (Think multiple content authors). In this scenario, a lot of content can quickly become very messy, when some poorly constructed, nested HTML (example a paragraph inside an li inside a table), will result in a lot of differently scaled text elements (yes I’d like to ensure the content being entered is clean, semantic, and thoughtful! but we have CMS for a reason
).
Because the em applied to each element will be calculated based on the items parent value, it is almost impossible to code for all possibly scenarios in which tags might become nested.
I could make all text elements be the same em by default, e.g 0.85em, but this would defeat the purpose and make for an ugly layout.
Every project has trade-offs, mine is using PX instead of EM, where I can control every elements font-size, regardless of how bad the html is. Accessibility issues aside (screen readers don’t care what your font-size is btw, and browsers now zoom content for poorly sighted users!) I’m happy with sticking with px
I work with web, as a pro, for >10 years already. I totally agree with Steves comment. From my practical point of view, all other units, except px, are either with overcomplicated behavior or for special cases of other media (like pt).
My points:
1. Try to explain the calculation of nested em or % units to your clients using CMS;
2. Try to explain it all to the new guy/girl student in team (doesn’t really matter be it designer or programmer);
4. Try to move some elements up/down DOM hierarchy some time latter. Take some more complicated rearrangement in a more complicated layout, with different people working over different time.
(I’m in writing mood today
so here’s some moral story.
———
Worst-case scenario for em or % usage in css:
Typical business day, after messing with yours beautifully designed, web sites content, with randomly nested elements, your (good and respectful) client calls you asking to move some hard coded blocks to some other places:
– Because, it doesn’t look nice, in a new present (did I mentioned “messed”?) content state, for me any more.
– Well (Of course it doesn’t, Mr. Obvious Respectful Client. You’ve messed it all up, by CMS’ing in a ways I’ve told you not.) … Ok! We’ll help you and fix it (any way, it’s just money, we can move your things twice a day if you want – at least it’s what you think).
– Hey new student guy, I have a practice for you. Take a look at this website. Move this funny “moto block” there and “new items list block” there. It’s just a 10-15 min task, at it’s most, do it in 30 and then go back to what you were doing before.
Oh… yes, of course, 10-15 min… Two hours latter, you find him still fighting em’s percentage battle. You sit there (to help), wondering who was that idiot (wasn’t it your self?) who made things in html so (complicated) nested. One hour later you stand (with proud pros “gotcha” face expression) and in a voice of Jesus say:
– You see, look good. It wasn’t so hard. You know, you just need to know few things, do some percentage math, few recalculations, follow 62.5% trick, remember default 16px font size… some blah, blah, blah…
Then your designer comes in:
– Hey guys, what ya doing? Moving blocks on that “award I’ve got last year” website? Let me look. Hey… it won’t go this way. You can’t just take it and move it. You’ve broken my horizontal/vertical grid and astrological/whatever-thinkcal harmony rules. Look, make this twice the size of that. That one 1/4 bigger to that, blah, blah, blah….
– Argh… Jesus math em all…
At last, three-four hours latter (1-1.5 of them are costly yours) job is done. You call client to tell it’s done, you’ll be charging him 85€ (just for example, as according to EUROSTAT it’s typical EU labor cost 22€/h *3,5hours +10% profit). You’d like to charge him more – but it looked such a trivial task and wasn’t agreed before, so you simply can’t. Now you are just trying to cover your loss of time.
And then, the last time bloody em’s hit the fan again. Client:
– I thought it was yours coding error, that after CMS’ing (editing) content your website became messed. I have a friend with website, I have some other websites, I (you name it)… and I know, that then they edit content, no visible mess ever happens there (yes, you’ve starting to get it right, they are all in px). I’m not gonna pay for your errors and definitely not 85€, and not even 5€.
– em… :/
So guys, the moral is, don’t make things overcomplicated, then unnecessary. Do 15min tasks in 10min, get for that 1-hour charge and make everyone happy.
Leave % for a profits, pt for a print media and avoid em… situations.
Notes
for mobile concerned, read: http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/
for disabled concerned: all modern browsers (even mobile) zoom px’ed fonts nicely with all your other content; screen readers concern about semantic tags (h1, em, strong, ..), not your font sizes.
Thank you thank you thank you Me and Myself! So often everyone gets so swept up in doing em based css because they see their own tunnel-visioned logic in it, but fail to realize the caveats of real world situations. It is definitely not just limited to CMS sites. It seems that CSS will always be something that people want to do ‘better’ and ‘different’ without thinking if overcomplicating things will have consequences. RIFLE IS FINE.
[...] David Calhoun also points out that from a stylesheet size perspective, if you’re using media queries to develop a responsive design, you might also end up with a giant stylesheet to take into account the resizing difference since px are not scalable in the same way ems are. [...]
Can anybody tell me please what should i use in css for make mobile webiste.
px or em or %
thanks
I just wanted to point out that you are incorrect about pixels not being a relative font size. As a matter of fact, px is considered to be a relative font size and is also recommended for screens as well as ems. Please see http://www.w3.org/Style/Examples/007/units.en.html.
@Aaron Maybe I didn’t make it clear enough in the article, but “relative” isn’t referring to the relative sizes between different screens, it’s talking about it from a CSS perspective, where ems are relative to their parent container and px isn’t. For instance, if you set a size on an element in em and change the font-size on the parent, the size of the parent changes relative to the size of the parent. This doesn’t happen with px, hence px are not relative (in size to their parent container).
Hi David,
I know you wrote this article about 2 1/2 years ago now, have you changed your mind since you wrote it?
Personally, I find em confusing, whereas px are easy to understand.
When I want to inspect an element in chrome, up pops the pixel count of the element. Easy!
I don’t want to know about the size of the parent element. I want that font size to be 12px!
Still, understanding and options are all good, so if you like using em, then power to you, bro!
ps. If I were you, I’d increase the padding on your submit button below. Perhaps put in 3px padding
Thanks for the advice! Doh, I’m not sure why I never bothered to fix that before. I made it plenty big now.
Nah, maybe I’m set in my ways (most likely), but I still like using em or percentages where I can. It’s just the style I do things I guess.
I know a lot of folks, designers especially, definitely like using pixels where they can. Definitely agree with your sentiments – no big deal, people like to do things differently.
Whatever works!