linear

[« New greymatter 1.3 template set: lefty] [Main Index] [CSS 101: meet DIV and SPAN »]

CSS 101: font control

01/14/2004

In the first of my series of CSS tutorial articles, we'll examine a basic use for cascading stylesheets: font control. This is the way a lot of webmasters get started in CSS; there's a lot of powerful tools to learn to use, and some very distinct benefits to using CSS for font control.

There are eight properties in the CSS2 standard that relate to font control:

the CSS font-family property

A font-family property sets the desired appearance of an element. (Not a page, since there are no page CSS rules.)

You declare what font you prefer most first. A specific name such as Verdana is a good example.

You can specify any number of specific alternatives that are next most preferable. Arial kind of looks like Verdana if you squint your eyes funny, so you could specify it next.

And then you usually want to mop up the people who haven't got any font on their system whose name you could guess at. You do that with a generic-family specification, of which there are five: serif, sans-serif, monospace, fantasy, and cursive. The user agent (browser) will pick a font that's installed that meets the general need, and you've somewhat gracefully allowed a Linux user (say) to view your page in a manner resembling your intended font choices, but without having to know what specific fonts the guy has on his machine.

The usual formula seen for body text is "Verdana, Arial, Helvetica, sans-serif" or some minor variation on that.

Why?
1) Verdana is way more readable than Arial at small point sizes, because the letter spacing is better.
2) Arial is second best because it looks decent at small sizes too for most machines.
3) Helvetica is common on Macs and other machines that may be missing your other choices.
4) sans-serif is the catchall. Everybody's CSS-compliant browser will have a font that vaguely resembles what you want.

the CSS font-size property

This lets you control font size in a variety of ways: by absolute size (such as x-small, medium, or xx-large), by relative size (such as larger or smaller), by percentage (relative to the size of fonts in the parent element), by length (in em ex units, which are relative to the base size of the font, or in px units which are absolute in size relative to the display).

Here's one of the hottest battlegrounds in the CSS world. All those different ways to specify how big the text is, and they all suck. They all suck differently, just for bonus points.

The only way to really control the size, and know you did it effectively is to use px units. A pixel is a pixel, whether Mac, Linux, or peecee.

But, that violates one of the original idea behind HTML, the idea that a user can adjust the display of elements locally. If you have a wheel mouse and IE, try holding the ctrl key while you spin the wheel. It's a significant usability enhancement for visually impaired users to be able to change the font size of a page that way. And using px units in your font-size properties kills it dead. (This page is a working example of that--you can't manipulate the font size in that manner because I use px units in my stylesheet.)

But, all the other choices suck, a lot. And in a variety of different ways across browsers and platforms that make it an impossible issue to deal with.

Zeldman does this better than I do, so I'll let him explain.

the CSS font-size-adjust property

I need to quote the spec to explain this one: "This property allows authors to specify an aspect value for an element that will preserve the x-height of the first choice font in the substitute font."
And that's useless. Seriously, only typographic control freaks from hell would even reach for that one. And even then, their victory would be hollow, since no broswer currently supports it.

the CSS font-stretch property

This one allows manipulating the width of the text by slecting a condensed or expanded face from the font family, thus giving you faux versions of "condensed" and "expanded" fonts.

Got any browsers that support this? Didn't think so.

the CSS font-style, font-variant, and font-weight properties

Now we're talking. Something you can use.

<span style="font-style: italic">foo</span> is the new, cool way to write <i>foo</i> and <span style="font-weight: bold:>bar</span> is the new, hip way to write <b>bar</b>. Why is that such a quantum leap forward? Well that's a little CSS philosophy. The new way is strictly presentational markup, and the old way is a blurring of structural markup that people frequently (okay, always) misused as presentational markup. So people who give a rat's ass about semantics will obviously prefer the span tag styled with some presentational rules. of course doing it for real you'd assign a class name and have a rule for the class that sets all the presentational properties, because inline CSS is bad for dozens of reasons.

Out of that list, only the small-caps trick represents functionality you didn't already have with "old-school" markup. You can argue about oblique, but I don't think any browser implements it per the spec.

the font CSS property

The font property is a shorthand way to express a collection of the other properties in a single declaration. All the other properties can be combined into a single declaration, which can make your stylesheet shorter.

h1 {
font-style: italic;
font-weight: 900;
font-size: 18px;
line-height: 24px;
font-family: Verdana, Helvetica, sans-serif;
}

is equivalent to
h1 {
font: italic 900 18px/24px Verdana, Arial, sans-serif;
}

The order isn't significant, since the different property values are distinct enough to be not confused. The exception is that you need to use the format 18px/24px to express the font size and line height if you use both, since they are formatted the same way.

Okay, so CSS font styling is like a toolbox filled with screwdrivers. About half of them you'll use every day, and some even make a decent chisel or prybar. The other half aren't good for anything, cause nobody makes screws that they fit into.

So how exactly is this an improvement over the font tag?

Factoring.

Let's say you want to put this month's calendar on a web page. You crank out a table with five rows and seven columns (or is it the other way around?). And in order to match your site, the text needs to be Verdana, blue, and the whole arrangement has to fit into a space that's 250 pixels wide, so you have to shrink the font some to wedge it all in.

In a world without CSS, you have to wrap every table cell's contents with something like this:

<td><font face="Verdana, Arial, sans-serif" size="1" color="blue">foo</font></td>

I've seen plenty code barfed out by WYSYWIG editors where there were actually nested font tags that did the same thing, just more verbosely. So whatever the deal, you have to do it 35 times, and maybe an additional seven if you have a header row in the table. That really adds up. In my little example, 69 bytes of font tag markup * 35 table cells is 2,415 bytes.

But, with CSS in your arsenal, it can be accomplished with a single rule:

td{ font: 10px blue Verdana, Arial, sans-serif; }

49 bytes.

And for bonus points, it can go into a separate file from the page. That way the browser can cache it separately from the page, and it can be reused on other pages.

The benefits, in case it's not obvious:


text, scripts and images copyright © 2001-2011 . All rights reserved.