Best practices for specifying font sizes?

I'm curious about this...

When I first started, I used pt, because it was the system I understood. Since then I've used em, because somewhere or other I got the idea that this was a better way. Sometime after that, I found YUI and their system of using %'s (which can be a little bit tricky, I suppose, with inheritances).

So I'm wondering: what are you guys' thoughts on this. What are the drawbacks/strengths of each?

I'm also curious about if there are ever any good reasons to use px for font-sizes. And if you use %, or em, do you still specify margins, padding, text-indents, letter-spacing, in pixels?

 

%/EM is superior for me, just because I am one of those mythical large font/120dpi users, so my default font size is 20px, not 16px. % is pretty much identical to EM's, just * 100, use them as such. Whenever possible you should be using %/em, particularly on content sections.

There ARE good reasons to use px -- underneath a image replacement (gilder-levin type) for example, where if the text auto-resized it would peek out from under the image or throw off the sizings. (still borked for certain FF users who still use the re-re idiotic 'resize text only' zoom like they're still using nyetscape 4 -- you know what, **** em!). In narrow columns where word-wraps from resize could result in unpredictable behaviors... and in footers on 100% min-height layouts since gecko based browsers act like rhesis monkeys on crack when it comes to calculation %/EM for height the same way.

It's just don't go hog wild using PX on everything, particularly the part of the page people actually visited for -- the CONTENT. You want to dick around in the page header with them or in a sidebar -- fine... but don't **** the content!

... and for the love of god, remember to ALWAYS set your line-height when you change size; and that stupid malfing "if you omit a metric on a line-height it will inherit to everything" crap does NOT work, no matter what the {string of expletives} "experts" at Sitepoint will try to tell you.

Though if you are practicing fluid, semi-fluid or even elastic layout (I like a mix of elastic and semi-fluid), responsive layout, and taking a 'content first' approach with semantic markup and separation of presentation from content, avoiding all the 'gee ain't it neat' garbage people are crapping all over websites with and the "but I can do it in photoshop" BS, %/EM is simple. REALLY simple if you declare the most commonly used size on BODY, and then only adjust it where it needs to be adjusted -- like on headings.

Naturally though if you're still sleazing out HTML 3.2 and slapping 4 Tranny (or these days the 5 lip-service) on it, based on some stupid "I can haz the intarnets" PSD jockey pretty picture of a website that has nothing to do with accessible or dynamic layout, using massive bloated idiotic CSS 'frameworks' that defeat the point of using CSS tied to endless "gee ain't it neat" javascript asshattery -- well, dynamic fonts is just as alien a term as WCAG.

Many many moons ago I wrote a page showing the difference in font rendering metrics, and how each browser AND OS handled it.
http://battletech.hopto.org/html_tutorials/fontCompare/template.html

The auto-resize in IE and Opera being the ENTIRE reason you should be using %/em... and even though all the other browser makers go "Accessibility, what's that" and ignore it, you can still manually set the default larger in browsers like Firefox and Chrome.

Bottom line, remember the entire REASON HTML exists, and why CSS was added to it!

HTML is to deliver content in a device neutral manner, your markup should say what things ARE, not what they are going to look like on any given target media. It is up to the discretion of the user-agent (aka browser) to best determine how to show that markup within the capabilities of the device, be it a modern 2560x1440 IPS, to the 1120x832 NeXT workstation TBL was working on when he made the first browser, to the 21x22 text mode of a sinclair ZX80... to a 64 column DEC teletype -- doesn't matter. Without CSS your HTML should be functional and usable on ALL of them. (something HTML 3.2 pissed all over and we've been trying to clean it up ever since!)

CSS exists to allow you to customize the output to EACH target, telling the browser how to handle your elements. Presentation, that's it's job.

Dynamic fonts, fluid/semi-fluid/elastic design, and responsive layout all play to this idea, having a device neutral base, then tailoring it to both the capabilities of the user-agent and the preferences of the user.

A concept that seems lost on most of the people dicking around in Photoshop and then having the cojones to call themselves "designers"... when to be frank they don't know enough about font sizes, rendering capabilities, target devices, HTML, CSS or accessibility to be designing Jack! No matter how pretty their nonsense may be, it most always ends up useless to a large number of users -- that's why the real successes of the Internet -- google, amazon, e-bay, slashdot, facebook -- probably don't have someone sitting around spanking it all over Photoshop with the mouse and calling themselves a designer.

At least not until recently... given how many of said sites are a shadow of their former glory in terms of accessibility.

 

I love your passion, deathshadow. You ought to sit down and just write a whole dang book - best practices for everything web design. I'd buy it

 

Percentage all the way would be how i would go , right now it's pretty much the only good option .

 

Oh, here's a question, then: if you set line-height every time you change size, how do you set it? Percents?

 

I usually try to use the same metric I used on font-size... Though by the time you say both font-size and line-height separately, you're almost up to as many characters as the condensed FONT property, which is why 99% of the time I change the font size, I just restate the entire bugger just to be sure.

Like what I use on body for 99% of sites I deal with...

font:normal 85%/140% arial,helvetica,sans-serif.

But I like tall line-heights, 140 to 160% depending on the font. Improves legibility IMHO. The default 110-130% suggested by the specifications (which ends up 120% in everything but gecko, which seems to randomly vary +/-5% even on lines declared the same) can make long lines harder to follow. (though really that's what semi-fluid+elastic layout is for as well).

 

Since we're talking about font sizes , what do you think about vertical rhythm based on the golden ratio ?

 

you should definitely use separate CSS file for any decoration and formatting.

 

Apocalypse, that's an interesting one. I'd have to say that's a matter of visual preference.

death, I learned sorta the hard way about the wacky way line-height doesn't exactly inherit, so you were right on about needing to specify line-height at every font change. Do you ever specify unitless line-height? That seems to introduce a little more sanity in the process but I'm not too sure (having never put it to practice myself).

I'm tearing up and restyling the css for a message board, which is a big ole' headache, having to deal with tons of pre-existing stuff that might be crap, and just not knowing where to look at times for a lot of things. I started out defining the font as 100% in the body, but it's getting clear to me that I'm better off redoing that as 85 or 80% from the get-go, and making whatever I need larger, from there. Good call.

 

px will work on all major browsers

 

That's what I was talking about when I said 'no metric' -- omitting what the number means. It appears to work for 96 dpi users on everything but Opera, and it fails in Opera... randomly. In both IE and Opera at 120dpi it works on my desktop currently, but falls apart miserably on my laptop despite running the same browser versions and OS versions on both -- I actually suspect it failing can be tied to the video drivers (of all things) as that's all that's different between said machines. My daring to argue that it doesn't work got a bunch of ostrich's panties in a twist since I tried pulling their heads out of the sand, only to have them switch to concrete for their blinders instead. Shocking when you post screencaps of the advocates of said techniques websites broken as all git, and they STILL have the cojones to defend it as working.

85% works well because of rounding differences across browsers. 80% will give you 16px in some browsers at 120dpi, 17px in others. 85% always gives you 17px. Older versions of iCab (yes, I test for iCab) will also give you 13px at 80% instead of the more desirable 14px.

 

Dimestore hoodoo, Five and Ten voodoo.
Wait, that's probably too old a reference...

Typical nonsense of trying to take a mathematical concept completely unrelated to anything visual, and use it to justify ugly/wasteful layouts and/or make something sound more impressive than it really is. It usually results in too much white-space, inconsistent white space, for the net result that most every site I've seen trying to do that looks more like one giant broken rendering error than intentional design. It also reeks of "but it works in print" nonsense, since golden ratio for layout assumes the entire page fits on the device -- websites usually don't or at least can't predictably be so, that's why we have scrollbars. There's a LOT of stuff from print you'll see touted as sensible, that doesn't work when targeting different size media with different levels of accuracy. See serif fonts, which are 'more legible' according to every print expert, but fall apart miserably on screen since most displays prior to 'modern' LCD's ran at a physical 72 to 75 dot pitch... and even now most 1920 wide 21" 16:9 to 24" 16:10 displays barely tickle 90ppi. (which is why the OS default of 96dpi is 100% nonsense). There aren't enough dots to render serifs legibly at anything less than 16px -- and to be frank even 18px is pushing it... What works in print is a steaming pile of /FAIL/ on screen.

I rank 'vertical rhythm' based on the golden ratio with the noodle doodle concept that prime numbers are somehow magically more secure (because narrowing the selection of possible numbers slows down brute force...), stuffing words that don't even exist inside BODY into META['description'] and/or META['keywords'] helps with SEO, or that science can be used to prove religious dogma...

They call their {expletive omitted} science like the word could give them cred.
If them {expletive omitted} be scientists then cap me in the head.
-- MC Hawking

Golden ratio is the feng-shui of layout. NO, that's not a compliment.

 

Thanks for the opinion . I've attempted to use it a bit . It does produce some improvement but usually you have to adjust the whitespace .

However trying to be closer to the golden ration when it comes to layout works out pretty nicely . However vertical rhythm has nothing to do with good layout as far as i can tell . Design is by eye and no amount of math can ever decipher it .