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:
p { font-size:14px; margin-bottom:16px; }
h1 { font-size:18px; margin-bottom:26px; }
Now that my fonts are specified in ems, how do I set the bottom margin? Percent? Something like this?
(Although I’m sure my math is wrong, I got my numbers using Ethan Marcotte’s target/context=result.)
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.
You can also use ems on your margins and padding. I’d say tinker with the settings until you get the spacing you want (but test cross-browser, as calculations can differ).
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:
[list][]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.[/list]
Now, assuming that:
[list][]1 standard em = 16 px and
[]you want a standard paragraph font size of 14 px and
[]you want a standard paragraph bottom margin of 16 px and
[]you want a level 1 header font size of 18 px and
[*]you want a level 1 header bottom margin of 26 px,[/list]
as your example suggests, then you want the following CSS:
html {
font-size: 1em;
}
p {
font-size: 0.875em; /* 14 divided by 16, or seven eights */
margin-bottom: 1em; /* 16 divided by 16, or eight eights */
}
h1 {
font-size: 1.125em; /* 18 divided by 16, or nine eights */
margin-bottom: 1.625em; /* 26 divided by 16, or thirteen eights */
}
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:
Avoid percentages on anything other than font-size, line-height, width or height. Using them on padding/margins can be a little… off.
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…
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.
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)
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)
and it does NOT inherit properly or even set the value properly on 120dpi systems in either Presto or Webkit. Omitting the metric on your line-height does NOT propagate properly in all browsers.
Christmas on a cracker, I’ve said that like fifty times now. But of course, EVERY time I say it doesn’t work someone comes back with “oh it’s fine, you’re full of…”
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
Don’t most new websites already have that with the giant idiotic animated banner rotating bull the art nudniks go and fardarbn perfectly good websites with? Sites need that ein loch in kop.
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…
Basically the difference between:
FF – value*percentage/100, float stored for layout, floor used for rendering.
IE – floor(value*percentage) div 100
Old Opera – value*floor(percentage) div 100 (all values basically integer!)
Current Opera and webkit – floor(value*percentage/100)
/ being a floating point divide, div being an integer divide
