In an effort to create more responsive web sites, I'm finally learning the ins and outs of flexible sites.

One question that has me stumped right at the get-go is how to have a flexible bottom margin to <p> and heading tags. In the past, I have reset <p> and heading tags to zero margin and padding. Then, later in the style sheet, I set the bottom margin to whatever is appropriate. So, if I might do something like this:

I did a lot of googling about this yesterday, and was very surprised I wasn't able to find my answer. So I'd also like to ask if there are any good resource sites out there yet for responsive web design.

And finally, is there a way to make a font's size relative to the body element rather than its parent element? Having to keep track of that might drive me bonkers.

Margin and padding isn't relative to the font size of the element. I gather from your example that you assume that 1 em = 16 px. This is a wrong assumption, for two reasons:

Traditionally, the em measurement is used in print, where it equals 16 pt. You can't make a reliable conversion between print and screen measurements, simply because they are different medias. Some operating systems thinks that 1 pt = 1 px, while other thinks that 1 pt = 1.25 px. This makes the use of the pt measurement unreliable.

For web design use, the em measurement is used relatively to the user's preferences. Therefore, you have no way of knowing what 1 em actually is - it could be 8 px, or it could be 72 px. That's why it's such an excellent tool: it allows you to respect the user's preferences, while still retaining control of the relative appearence of elements.

This is fairly low-level math, by the way: If you assume a standard em is 16 px, then 2 px equals one eigth (0.125) em, 4 px one quarter (0.25) em and 8 px one half (0.5) em. In other words, with a minimum of effort, you can easily figure out the ratios in your head, by using simple addition.

Christian is correct in pointing out EM isn't fixed in what it means for PX -- sure for 96dpi users 1EM == 16px, but on my machine which is set for 120dpi, 1em == 20px.

Some advice:

1) Avoid percentages on anything other than font-size, line-height, width or height. Using them on padding/margins can be a little... off.

2) if you change your font-size, restate your line-height! Even if you are setting it to the same value you CANNOT trust the inheritance... As a large font/120dpi user I see so many broken/unusable layouts caused by this simple omission where someone used EM to "help" accessibility for different font size users, but by failing to restate the line-height in fact flushed it.

In my code, the condensed property ends up about the same number of character as saying "font-size:85%; line-height:150%;" that I usually say "screw it"... and restate the whole condensed property... Well, compare:

font-size:85%; line-height:150%;

to

font:normal 85%/150% arial,helvetica,sans-serif;

Oh noes, like ten extra characters... really the latter seems the most reliable and foolproof -- you'll see people take all sorts of shortcuts like omitting weight/style, omitting metric on the line-height -- and invariably it breaks SOMEWHERE. (usually on my machine!)... the full condensed property as above even if it's restating values is still the most bulletproof approach. Remember, they're called shortcuts for a reason...

3) due to rounding errors, 0.875 will give you 15 on some browsers, not 14px. It's why I use 85% instead... which also gives large font/120dpi users a more comfortable 17px instead of 18px. I suggest testing your math against at least the three main choices in Win7 -- 96dpi, 120dpi and 144dpi just to be sure of what you're getting, but always be aware that you CANNOT predict the user settings -- which is WHY you should be using %/em in the first place.

4) state your leading zero on decimals, some browsers may mistake that for a new class and bugger the whole property. (though I think the last mainstream browser to screw that up was either Opera 7 or Mozilla Suite 0.9 -- it's still bad practice)

5) even when using px, I usually state my bottom padding and/or margins in EM... not sure why. Usually I find 1EM looks best with a 140-160% line-height. (much larger than the default 110-130% you'll find across all the browsers)

Regarding line height: This should usually be stated anyway, to aid readability. A good line height is between 120 and 150 percent, depending on font size and face.

Funny thing is, every year for the past three it seems like I've added 10% to my default line-height... while for the most part sticking to arial,helvetica,sans-serif. At this rate I'll be at 200% by 2015

Wow, I thought no one had responded to this. Thanks for the input. For font-size, one of you is using ems and the other percentages - care to duke it out? I must admit I'm used to seeing ems. Deathshadow, why do you use percentages for font-size?

Wow, I thought no one had responded to this. Thanks for the input. For font-size, one of you is using ems and the other percentages - care to duke it out? I must admit I'm used to seeing ems. Deathshadow, why do you use percentages for font-size?

Functionally there's no real difference... I pretty much use % on fonts because it's all in the same keystroke area and as such faster to type.

100%/140% is eight primary keystrokes on the same row, one bottom row and two pinky ones. 1em/1.4em is spread out all over the keyboard.

Really there's nothing wrong with saying both in EM... I just prefer % as I type it faster. Well, there is one other reason. Granularity.

With my years of programming background I've had it drilled into me that any time you introduce fractions you introduce the possibility of errors cross platform AND make things slower. With fonts this probably doesn't apply, but being able to say 50% instead of 0.5em -- thereby not using a decimal point just feels 'better'... though that could just come down to implementation... I mean, how do they handle percentage in the various browsers? I know FF treats EVERYTHING as floating point, IE tries to still do integer optimizations (which actually I agree with) and Opera/webkit being somewhere in the middle (I suspect they use floating point operations and then truncate the result to integer without storing the float).

Though I know for a fact opera used to do nothing but integer operations throwing away fractions of a percent in the process...