In theory, the + operator is brilliant. Instead of being boring, and only doing one thing, it can be used for both numerical addition, and string concatenation.
That's fine, you might say, but tell me; have you ever considered what happens when you want to add together two numerical strings, or concatenate two numbers?
The astute members in my audience might have realised (if they're reading via a web browser) that the site has recently undergone a bit of a re-jig. Not just on the outside, but also on the inside. As well as using all the nice class features of PHP 5, the site now has a completely elastic layout.
What's an elastic layout? I hear one person cry! It's a new name for a layout paradigm which has been technically possible for a while. Basically, it means that the whole site's layout resizes according to the browser's default text size — not just the text in the site. This is a leap from liquid layouts, as it means that the site effectively zooms in when the browser's font size is increased, and zooms out when the browser's font size is decreased.
This isn't actually that hard to achieve, but few developers that I've seen appear to have picked up on it. Even those who have implemented it have typically left borders and padding with absolute values rather than relative ones. I would argue that this isn't a very good idea. Let's assume (for the sake of argument) that you have a nice big 50" television linked to the Internet viewing an elastic web page which has absolute sizes for the paddings, borders and margins. Looking at the screen from a couple of metres away, and assuming standard margins and paddings of 5px, and borders of 1px in width, the text would almost run together, and the margins, paddings and borders would not be discernible. This can't be good, and this is why I believe that every measurement in an elastic page should be elastic, and use relative units (barring special cases where images have to be used and alignment is critical: as images for the web are almost completely bitmap-based, absolute units still have to be used here).
The most commonly-used unit with which people implement elastic layouts is the em. This unit originated in ye olde typography, and is the height of a capital "M" in the current font face. (Note that it is not the width of the capital "M", as sometimes believed, although this usually applies, as "M"s are usually square in standard font faces.) The em migrated to CSS in the first version of CSS, but hasn't been used too much since (remember debates about relative-vs.-absolute font sizes?).
The main thing to remember about ems is that 1em is equal to the current font size in points. Therefore, 2em is equal to double the current font size in points!
The other thing to remember about ems is that they multiply together to generate the final dimensions. So, if you had a parent element with font-size: 2em;, and a child element with font-size: 0.8em;, the final font size would be 1.6em, relative to the parent element's parent (in this example, we can assume that its font size is just 1em). This works exactly the same way for other properties using em units, such as padding or margin, although you must bear in mind that it's always relevant to the parent element's font size.