Burningbird

Mixing serif body and sans-serif titles is not a sin, at least not in my book. I like the letter-spacing you're using in your titles, too.

I'd personally think about going san-serif for the page title to match the post titles, however. I'd also try to make the sidebar text work as Georgia… it may or may not work, since Georgia's a fairly loosely set typeface, but it's worth trying.

Looking at the individual entry archive, I notice that the About This Entry box is out of sync with the rest of the sidebar boxes. The title of the box isn't centered, and there's sans-serif and serif mixed in the box itself.

In general I think this is a really nice layout, though. My nit-picks are precisely that.

Looks good in my browser (Firefox). Georgia has been my favorite for blog posts for a long time now. Very easy on the eyes, given the anatomy (stroke, ascender and descender heights, etc.) of this type.

As for mixing serif and sans serif: it is traditional to have a sans serif typeface for titles and serif for chunks of text. Your kerning, or letter spacing, in the titles is a bit tight, now that you mention it. I wonder if small caps would give the illusion of more space, even with that tight kerning … but of course, small caps would make it look more formal. Besides, it's fine as it is … it's just that you pointed it out, so we all look at it more closely now!

What maria said. And it might be worth a play trying the title a little larger and in bold (?) to create even more contrast.

Is Georgia the new Arial/Verdana?

Ick. On my system (Mandrake 10.1 Linux + FireFox 1.0 + 1280×1024 LCD display), Georgia's letter-spacing is flaky at smaller point sizes. In the word "design", for instance, the e, s, and i are all run together in one smear. On the other hand, the letter "o" has huge spaces around it, so that "book" comes out more like "b o o k".

Not nearly as bad as the Lucida Grande that WordPress 1.2 used for their default theme… that was essentially unreadable due to poor letter spacing. But the Georgia is hard to read and not very pretty at all at the current point size.

I don't think it's really a problem with Georgia. I think that it might be a problem with the font renderer in Mandrake, because no serif font looks good at small point sizes, with the exception of the default font called simply "serif".

Not that I have any real suggestions, other than to go back to sans-serif fonts. Well, yeah, that's my suggestion. Serifs are hard to render cleanly on the limited resolution of a computer screen, and I've never cared for them. Besides, to me a serif font (for body text) gives writing a strong cachet of "behind the times."

Bryant thanks for note on the About box, and I've fixed it to use all the same font — verdana.

I'll play around with the title bar, Maria and memer. I think I need to look at it in my Windows machine when I do.

According to the book, verdana and georgia are the most commonly used fonts. It recommeds trying others, and then if they're not installed, these are used as backups.

Doug, I am sorry this is less than legible. Could you send me a screenshot of this? I really do like the georgia and would hate to lose it, but I don't want people not being able to read my posts.

Doug, the funny thing is that serifs generally are supposed to be easier to read/scan than non-serif. Took em a long time to come up with non-serifs that work well enough for computer screens.

Have you tried the ol' 'ctrl+' trick for Shelley's pages? Every once in a while I find I have to do that for specific sites. If that don't work, hie thee to a respectable distro like Ubuntu, will ya? ;-) Isn't Mandrake perpetually in RC mode? ;-)

Shell, will your pages degrade to Times or plain 'serif' if for some reason someone doesn't have Georgia?

Right now, memer, it degrades back to the verdana et al. I am thinking of degrading to Times and than serif.

Shelley, I like it. (But I prefer serif faces for body text.) Using serif and sans-serif faces on the same page only becomes distracting when people try to use them both in body text.

It looks good on my Firefox (on WinXP). Linux users will need to have properly installed the Microsoft free TrueType web font set that includes Georgia. Alas, I can't answer any advice on how to do that given the multiplicity of font management and TrueType engines used by the various distributions. I'll have to boot into SuSE later and see how it looks there.

Like everyone else who's commented I think that Georgia is a vast improvement over Arial (which is what you were using previously, if I recall correctly).

However, since you've specified your font sizes in either points or pixels (both absolute units), the text doesn't rezize at all in Internet Explorer for Windows — which makes the site less accessible. The reason I checked is that I use Georgia too (I allow visitors to switch to Verdana if they want) but your Georgia looks much better than mine on the Macintosh and I was interested to see what font size and leading you'd set.

Regarding the legibility of serif vs sans-serif faces, I think that serifs are only easier to read on a printed page. On a computer screen, x-height plays an important role and Matthew Carter designed both Georgia and Verdana with large x-heights (meaning that the height of a lower case "x" is relative to that an upper case "X" is much greater than for a font such as Times).

Tim, it's good to know that there is a font set for the Linux users. I'd hate to have to change, now.

Jonathon, no I had gone to verdana, using arial as backup font.

I'm actually using the setting that's in the default stylesheet for the CSS Zen garden template, which is:

font: 10pt/14pt georgia, serif;

Would it be better as .em instead? If so, do you have a suggestion as to a good replacement for this meansurement in em? And I'm a bit hesitant, too, because in the book, em could change based on browser.

I like Georgia, too — it's what I've been using on my page for a while now, although in a slightly larger size than you've got here, and yeah, I degrade to Times and serif. I'm using Lucida Grande for titles and the sidebar.

I thought that ems were relative to the font size. Is it different in CSS than from the rest of the type world? At least according to everything I've read, you can't specify a type size in ems, because the em depends on the type size. I'm not that strong in CSS, but as far as I'm aware we're left with relative type-size-names like {…, x-small, small, normal, large, x-large, …}.

I've used the line-height CSS selector to control leading. It can take a percentage. I've assumed that's a percentage of the type size, but I may be wrong. I should probably go back sometime and check the aesthetic proportions in my line-heights, since I've been working off a standard MT template and haven't yet taken a real rigorous look at that aspect of the page type. I just went with what looked good to me in my browser, and we know how well that works.

Jonathon's got a good point about x-height in typefaces for screen display. I'd forgotten about that.

Speaking of leading and line height:

Jonathon, the element inherents a line-height of 140% from the container element.

Actually, scratch my last comment as blather. I must have been more tired than I thought last night.

Shelley, the whole font sizing issue is a can of worms. Text can be specified in points, picas, pixels, ems, exes, percentages, and with keywords (relative or absolute). Since it's generally accepted that points and picas should be avoided because they're units for printed media, I'm honestly surprised that the CSS Zen Garden default stylesheet uses points to specify the font size.

I'd better tread carefully here, though, since I don't claim to be a CSS expert. But text specified in points can't be resized in WinIE and can also look different on different platforms. Pixels are consistent across platforms but the text can't be resized (in WinIE) so again it's a significant usability/accessibility problem.

Tim, it's exes that that are relative to the font size. If you set the font size to 1ex, then in theory the height of the uppercase letters will then be equal to the height of the lowercase "x" if the font size had not been specified at all. Except during a leap year, or if you had your fingers crossed when you set the font size using exes. Just kidding. But, as you've probably figured out by now, exes are a bad idea (mainly because browsers can't figure out the size of an ex accurately).

That leaves ems, percentages, and relative (smaller, larger) and absolute (xx-small, x-small, small, medium, large, x-large, xx-large) keywords. All of these allow the user to resize the text but you have to be careful because nested elements inherit their initial size from the parent element and then adjust their size accordingly. If you have nested elements specified in percentages less than 100% you can wind up with tiny text quite quickly.

I use a mix of keywords and percentages at the moment but I'm thinking about switching to ems.

I've also been meaning to buy the CSS Zen Garden book so I'll be interested to read what they say about font sizing. In his book, Web Standards Solutions, Dan Cederholm avoids the issue entirely (unfortunately).

(And I'm relieved that you decided to scratch your last comment though I thought it had something to do with the 10pt/14pt declaration.)

Yick. Sorry, I don’t like it. What’s with this new fashion to use serif fonts for long text on websites?

Computer screens just don’t have enough resolution to render the serifs well. The serifs should be very light, but you just can’t render detail any smaller than 1px on a screen. Georgia tries to counterbalance this by fat strokes which can properly dominate over the serifs in the type face, and that works reasonably well, but it also means that at low point sizes the font looks chunky and smeary, and is much less readable than a sans-serif font at the same size. It doesn’t begin to look good any sooner than about 20px. It is gorgeous at large sizes.

In general, the rule of thumb in print is serif for the text and sans-serif for the headers, while on screen, it is the opposite.

That also clears the point about mixing fonts being a faux-pas. A faux-pas would be to apply different fonts to the same thing, like having some paragraphs be formatted with one font and others with another, for no particular reason at all. Fonts should

As far as sans-serif fonts go, choices are unfortunately limited on the web. Arial rather sucks. You could do the typical thing and use Verdana like the other 348,893,474,681 websites out there. If more individuality is what you’re after, you can try Lucida Sans for Windows people and Lucida Grande for MacOS X folk.

I wish the Bitstream Vera (download) family would spread beyond the Linux crowd; not hard, considering it’s free in both senses. These fonts are great: the Serif is very similar to Georgia, and is decent; the Sans is great, Verdana-ish but warmer, more elegant, more readable; and the Sans Mono is just drop dead gorgeous.

I will say, though, the increased default font size is a godsend. Tiny text is my #1 peeve with designs on the web.

Oops, forgot to finish the 3rd paragraph: Fonts should signify something about the role of the text they’re applied to, and two different pieces of text that have the same role should have the same font applied too.

Aristotle, and others who have problems with the serif font (and it sounds somewhat like a Linux thing), I've added a switcher so you can pick.

I should increase the side of the san-serif font, too. It is smaller than the serif.

Thanks!

Two issues you might want to address: It looks like you've used relative sizes in the layout, so the differing font-sizes cause the navbar to shrink or expand depending on which font I pick. And the buttons are causing the "Contact Shelley" link on the navbar to wrap onto two lines.

Thought I would add to the conversation, mainly about how font sizing works in css. As has been mentioned above we don't get to use absolute measurements for font size because internet explorer has issues with absolute measurements (actually ie has issues with lots of things). By absolute measurements I mean things like pt, mm, cm, inch and so on. It would be nice, but hey.

So what we do is use relative measurements, most commonly ems or percentages. These are relative to the current font size. Now it has probably occurred that if we haven't set the size explicitly where is the browser getting the size from? Well, from the browsers default settings. On windows these are 16px and, happily, on the mac too. In safari it is 16pt (which on the mac corresponds to 16px). The problem with the default font size is it is too large: 16 point (or pixel) type is just too big and looks ugly. Typically the body type would be set to something close to 70% of the default size or 0.7em and that would be great! But internet explorer has issues with ems: if you were to specify for the body font size 0.7em and the user has set the text size option from the view menu to smaller they get text that is about 3px tall. What's the solution? Set the font size on the body to 90%. This kills the ie font sizing bug (no idea why), and then use ems for all the other sizing you need to do. At least that's the way I do it - I like using ems - I suppose you could stick to % if you prefer. As for leading, the line height property can take a pure number (no units) like 1.5 which corresponds to a line height of 1.5em or 150%. Ems really do correspond that closely with percentages when used as a font size. Where they differ from percentages is they actually have a size in their own right. Which is a square with the height and width of the current font size, so a 1em indent in 12pt type is 12pt wide. This can be used to good effect if you want the proportions of your page layout to scale with the font size.

Hope this was useful.

Gahhhh!

Just teasing. Marc, thanks so much for taking the time to walk through this. Fonts (and character sets) are a weakness of mine — one I can't seem to wrap my mind around, though I usually have no problem with technology.

I will play further, experiment a bit.