PXPros: consistent sizing. Every browser and device interprets this value the same. 10px is 10px. Period.
Cons: Internet Explorer didn't allow resizing PX defined fontsizes untill IE9. It supported scaling, but it scaled the whole page, you could not adjust font size when defined in PX.
EMPros: adjustable font size in IE! and with the font-size: 62,5% trick in the body declaration it was even fairly easy to use (1.2em then equaled 12px). You can change all font sizes at once by changing the body font-size.
Cons: em-based font sizes add up on child elements. If you define 1.4em on an LI element, the first elements become 14px, but children get a 27px value... that can cause serious unexpected behavior. To avoid this one should define a 1em font-size on all child elements.
What now?So PX suck and EM suck maybe even harder. What should we do then? Well, there's a new kid in town and it's called REM and that's not a rock band, but another way to define font size. It stands for "Root EM" and it works the same as EMs, but with the difference that this unit isn't relative to its parent like EM, but to the root element (HTML). This solves the problem of inheriting font sizes by children and all problems caused by that. That eleminates all cons of the EM element and leaves us with exactly NO cons. Wow!
Can I use it in my work right now?
Ah yes... browser support. "look at this fancy stuff! It doesn't work on any browser, but look what the future has to bring!".... actually, this isn't one of those supercool bleeding-edge techniques. Well, it is supercool, but it is supported in most browsers!
Browser support for rem
This isn't a real problem. You can easily fix this by defining a PX based fallback for every REM value, but you can also use a supercool polyfill that automatically calculates and adds PX values in browsers that don't support REM yet (IE8 and earlier).