We’ve all read a magazine or a newspaper before. Noticed how text is usually split into multiple columns? Ever wondered why? Some folks figured that a human being can’t cope with really long lines of text and so decided that ideally, lines of text should contain about 60 characters. This is short enough for the reader to easily find the next line of text and still long enough to prevent constant transitions from line to line. And since newspaper formats are quite large and no-one would ever read them, if lines of text spanned the whole page, they decided to split text up in columns. And we like it that way.

A few years later, in 2001 to be exact, w3 said “Hey, our displays are getting too wide for one line of text as well”, and so decided to include multiple column layouts in css3. Years have passed by, and today, in 2008, Mozilla browsers and Safari support this feature. I’m not sure if any other browser does as well.

So how does it work? In a block of text, a web developer can specify either an optimal width of a single column, or the number of columns. He can also specify a gap between two columns, and… not much more. Given text would then be intelligently split into multiple columns of equal heights and widths.

So what are the downsides? As we all know, there’s one huge difference between a printed page and a webpage. A printed page will always look the same, no matter who or where reads it. A webpage on the other hand won’t. Some people may read it in a bigger text size, some prefer a different font family, etc. As good of an invention as columns were, some care has to be taken while using them.

First, and one of the bigger typographer’s fears, are the so called widows and orphans. These are single (first or last) lines of paragraph, which stand alone. Even though not all that disturbing to the reader, they look odd and are never supposed to be left in a printed page. The designer should take care of them either by modifying the text or applying a different design. But who’ll take care of them on the web, where lines may split differently for me than they do for you?

Researches show that text in columns is best readable when justified (you know, not left or right aligned, but both at the same time). But justifying short lines of text can lead to a few problems, such as oversized word spacing and rivers of white. This is regulated in desktop publishing by word hyphenation (splitting a word in two lines), but css draft of it is poor and “up-in-the-air”. But also with hyphenation enabled, a designer always has to check that something ugly doesn’t come out on the final print. Again, no-one can do this for websites.

I guess both problems can be minimized with proper implementation. But I have one more up my sleeve. In newspapers, text is optimized so when you reach an end of a column, you can easily move to the next one. That’s easily done by moving your eyes and head a bit. In websites, though, you read long texts by scrolling. Nobody can guarantee you that the height of a column won’t exceed you browser window’s height. So imagine scrolling around a page with 3 columns, all twice the height of your browser window. For all I know, you might have downsized your window and enlarged your fonts to achieve this, but that can’t be an excuse for ignoring this problem. It’s gonna be a pain in the ass. Scroll down, up, down, up and down again to read one block of text? No thanks. I prefer the “down down” technique.

So I’m not really sure I want to see any columns in web pages I’m reading. Except maybe if a website can guarantee a designer that’s gonna optimize splitting text into columns considering my browser, my preferred font families, my font size and my browser window size. It’s just not something a today’s browser could do on it’s own.

The need for columns is most obvious with fluid width websites, such as wikipedia and today’s wide screen displays. Mostly because people are still buying them to run their Internet Explorer in full 1920 pixels. Too bad no operating system allows us to run two windows side by side to better utilize the screen space.

And all this brings us to why I prefer fixed-width designs. Text is just much easier to read, when someone who knows what he’s doing takes care of it’s width. Just keep in mind, optimal line length on the web is cca. 30 to 35em.

We spend a lot of time reading text on the internet. This is mainly read on our computer screens. But reading information on a computer screen is far less comfortable than reading it on the paper. Because of that I often print out some longer articles to read them. And I’m amazed by how little people take care of such readers. Most of the time I get a paper full of useless info and links, which I can’t click anyway (or at least clicking them won’t do anything).

Example - CNN.com is a decent news website. A random article on the site might look something like this. Quite ordinary, really. But try printing this article. Or better yet, click “print preview” to save precious paper. See how bad it is? It is full of information you don’t want. I’d rather copy the news text into a text editor and print it there.

Now try doing the same with this article on A List Apart. The printed page does indeed look like an extract from a newspaper or a magazine.

“How do I accomplish a proper printout then”, I hear you ask. There isn’t much to it really. When presenting content, a browser knows which media it is rendering for. For instance, when reading a page on our computer display, the media is “screen”. For printed pages, media would be “print”.

One can specify the correct media type for each stylesheet on the page. Therefore this would include all the rules to show on screen:

<link rel="stylesheet" href="style.css" type="text/css"
        media="screen" />

And this would do it for a printed page:

<link rel="stylesheet" href="style.css" type="text/css"
        media="print" />

Now, does that mean you must create two css files, one for screen and one for print? No. You can cover both by saying media="all". So what I usually do, I create a default stylesheet with media="all" and include another one for print just bellow it. In there I rewrite some rules, which should be special for a printed page.

Things to look for are:

Removing unneeded elements

Interactive elements such as menus, banners, form elements, etc. might be useful on your page, but are totally unneeded on a printed page. You can specify a display:none; for them in print css.

Units

Primary screen units are pixels. But what is a pixel on the paper? This depends on the DPI, but you probably don’t want people with better printers to read smaller font. So try using units such as points (pt), millimetres (mm) or inches (in). A good font size would probably be somewhere between 10pt and 12pt

Colors and contrasts

Keep in mind that not all people will print your site in colors. Do check how your text and graphics look in grayscale. Fonts are usually best if black.

Backgrounds

By default, most browsers won’t print background images. So make sure your content looks ok without them.

Page width

The paper’s width isn’t 1024px or 800px. It’s usually 210mm (8.27 inch) for A4 or 8.5 inch (215.9mm) for letter. But there are paper margins to consider. I think you’re best of by not specifying any width at all, or doing it in percents

CSS does include some special rules for paged media, but as you might have guessed, most of them don’t work well in today’s browsers. The two that do seem to work, are page-break-before:always and page-break-after:always rules. These two, applied to an html element force a page break before or after it. Might be useful in cases such as when you always want a title to always start on a new page.

Preparing your website to print well usually doesn’t take much time. Just make sure to cover the basic stuff and do some test prints (different browsers and different printers, if you can). Visitors won’t get too bothered if there’s an input or a button visible, but they might get annoyed if a navigation menu doubles the amount of pages printed.

To start with, some theory
Nowadays, most browsers come with a default font size preference. We can change this setting, but browsers usually come with a default value of 16px, or 12pt. These two are usually the same, due to the 96 DPI assumed by most systems. You can test this here.

Another option that some popular browsers have, is the ability to change font-size on the fly. This means that while reading a page, user can press a certain key combination (usually ctrl + / ctrl - or cmd + / cmd - on a mac) to quickly adjust the font size. This is quite handy when only a certain website supplies fonts too big or too small.

The third important preference is the “minimum font size”. By setting this to, let’s say, 12px, we assure that no text on any website can be smaller than 12px.

What they tell us to do
With the default font-size setting of 16px, a large percentage of internet users is able to read text comfortably. A few facts might explain this. Also, W3C suggests designers to avoiding sizes smaller than user’s default font size. This would make sure website visitors have no trouble reading our site and are reading it the way they like to, since this is their preferred font-size setting.

The problem
All this sounds just too nice to be that easy. So, what’s the problem? Try asking your mother what her default font-size setting is. I bet she has no clue what you’re talking about. Most people don’t even know they have such a setting. And how many of the ones that do, have bothered changing it? The problem is, most sites don’t respect this setting so it would make no difference anyway. Therefore we can assume most internet users use a default font size of 16px. By following the W3C suggestion mentioned earlier, this should be the default look of most websites. But is it?

Is the default size okay?
Some designers, including myself, agree that 16px is a tad large for normal reading. For example, would you really prefer reading this over this? On the first screenshot you see an article on A List Apart with 16px set as minimum font-size and on the second with default settings. I prefer the second. But according most accessibility experts, the first screenshot should be the way to go.

I’ve been following a discussion on the WSG mailing list about using 16px or not. I’d just like to point out a few things:

• Of course, there are people with bad eyesight who have trouble seeing smaller text. But shouldn’t they be the ones to adjust the text? They can still set their minimum font-size to a value they’re comfortable with. No need for everybody to be reading enlarged text.
• On the topic of people with bad eyesight - Don’t they wear glasses or contacts to help them see better?
• People tend to enlarge text (as described in the first paragraphs) when too small rather than to shrink it when too big.
• Why don’t operating systems use 16px fonts if that seems to be the optimal size?

Are there benefits of smaller font sizes?
Yes, 16px is very legible, but it can cause problems. As you can see in the above screenshots of A List Apart, with bigger text, there is fewer content on the screen at a time. It becomes hard to quickly skim the page, a menu or a paragraph since there is just too little visible content. Also it requires scrolling more. Especially if you consider the 800×600 resolution.

The real world
So yes, in my humble opinion, 16px is too big to be the default size for most users. But on the other hand, it’s very good for them to have an option of customizing it. Users with bad eyesight have probably heard of the option to resize fonts. And they are probably using it. But I do think there are still more users that rather read smaller text. How did I come to that conclusion? Look at the web as it is today. How many websites really use 16px fonts? Not many. And I bet there’s a good reason for it. People obviously prefer it that way. And when making a website for someone, I’ll usually follow his or her guidelines, not those of W3.

I know, I’m confusing the default 16px size with user’s setting. But as mentioned earlier, sadly, these two values are mostly the same. If all users set this value according to their preference and not just keeping it as it is, the story would be different. In that perfect world, text size would be the same everywhere - the user’s preference. But such as it is, user’s find 16px too big and blame the designer for it.

A while ago, since I find 16px too large, I set my default font size to 12px. And what did I find out? That even though some sites respect this setting, they usually specify their fonts to be about 70% of the user’s default value. Which meant I suddenly had to read font sizes of 8 or 9 pixels. Now that is a bit small. So I went back to 16px.

Browser problems
As with just about everything nowadays, browsers have problems here as well. The first is, surprisingly, Internet Explorer. Along with 7.0, IE doesn’t have an option to change font-size on the fly. It does have a font-size option in the menu, but this is actually the default font-size setting. What it means is it will get overridden by something like font-size:12px; True resizing of fonts on the fly takes that value and enlarges/shrinks it as long it doesn’t go bellow the minimum size. Default font size is there just in case nobody ever tells the browser otherwise.

One other problem I’ve heard of just recently, is a problem with minimum font size. Some browsers seem to treat it badly. For example:

body { font-size:10px; }
p { font-size:120%; }

would mean that paragraphs should have a font 120% the size of body’s font, making it 12px. If we have minimum font size set to 12px this is ok. But some browsers would apply the minimum font size to the body, making that 12px and then apply 120% over these 12px, making the paragraph font size 14.4px. While testing this I noticed IE doesn’t even support setting minimum font size, safari and firefox do it correctly and opera doesn’t. See the test case. The text size should be 15px if minimum font-size doesn’t go over that. In opera you get a font-size of 45px with minimum font size set to 15px.

Web developer’s point of view
There are two ways of describing the font size. Absolutely, setting the font size in pixels, or relatively in percentage of browser’s default size (where font-size:1em; equals font-size:100%; or not setting the size at all). I used to do it relatively, to overwrite the (silly) 16px default size. But I figured there are two reasons why not to do that. First being IE users, who can’t resize the fonts this way. Secondly, I figured, should I really overwrite those 16px? Of course not. Now I usually set my fonts to something like 70% or 80% (of the default). This means that people who don’t know how or why to change the default size see fonts as I’d like them to and the ones who do probably already know that this rarely works as expected and also know how to enlarge the text if they have to. This is not the standards compliant way, but according to my calculations pleases the most users.

So I tend to keep most of my text at around 12 or 13px, but keep in mind that some users might change this. For example of what not to do I always like to link to this website. I find the design very lovely… until enlarging the text. It looks a bit funny after that.

Different fonts, different sizes
One more think I’d like to mention is that different fonts demand different font size. See a little demo here. It presumes you have all 4 fonts installed. Notice how Verdana still looks legible at 11px while Arial can barely be read.

Final thought
It’s nice to know the rules. Only with knowing them you can truly explain why you are breaking them. But don’t take it as an excuse. Always keep in mind that some people might not have the same eyes and the same display as you and that even though one font size is fine with you it might not be fine with your users. Font sizes can vary according to the content or type of users reading the page. And do try to offer the user an option to scale the font according to his or her likings.

Typography has been one of the main aspects of design ever since circa 3000 BC, when writing was invented. One can make quite some beautiful things by just choosing his font right and styling it correctly. But can we do it on the web? Can we use our own fonts?

Microsoft already solved this problem, way back in 1997. Internet Explorer version 4 brought support for embedding a font into a website, using css. Click here to see what I’m talking about. By using a special program, such as WEFT one is able to embed any True Type font with proper permissions into a website, by converting it into a .eot format. Nifty.
Let’s look at the css that does it. This is the main font style:

@font-face {
font-family: Piefont;
font-style: normal;
font-weight: normal;
src: url(PIE0.eot);
}

This would define a new font-family Piefont. It can be used as any other font:

p { font-family: Piefont; }

This would render all paragraphs in the font PIE0.eot. Now for some demos (IE screenshots lack font anti-aliasing, this is not necessarily always so):

• Demo 1 shows a simple page with an embedded font. See how it renders.
• Demo 3 illustrates what we can achieve by using special fonts. See screenshot.

Now this is great, I hear you say. Sure it is… for Internet Explorer users. But it doesn’t work in any other browser.

And what does W3 have to say about this? Well they defined very similar (if not the same) support for font embedding in CSS2, but it was removed by CSS 2.1, due to lack of browser support (or so they say). It’s being reintroduced in CSS3.

What about browser support? Currently font embedding is only supported in Internet Explorer, using the way described above. The w3 way, using True type fonts, however, is not supported anywhere.

I also recommend reading this ALA article for what can, or better yet, should be possible with font embedding.

So from a designer’s point of view, it’s a real pity we’re only limited to a few web-safe fonts. It does limit creativity. But from a surfer’s perspective, after seeing all the animated gifs, marquees, background sounds, etc., I’m really glad font-embedding isn’t widely supported.

To summarise what you should know as a developer - Using the simple “font-family: verdana, sans-serif;” to specify a font (and a font family, just in case) is still about the most you can do today on the web. But keep in mind that adjusting the spacing, line-height, etc. can do quite a lot. If you haven’t already, I suggest reading this website for a handful of tips on web typography. You can also use images for special fonts, but it comes with usability deficiencies, such as lack of font-size adjustments, broken searches and low quality printed pages.

I’ve had this problem many times before. I want to put the footer at the bottom of the page. Even when there is little content, I don’t want it floating around somewhere. I want it to stick to the bottom edge of the browser.

So here’s a solution I’m using on this very blog. How does it work? First it makes sure that both body and html are of at least 100% height. Now by applying position:relative; to the body, we can absolutely position our footer inside of it. And make sure the body gets stretched when there is more content in it that fits the browser window. Using min-height:100%; does the trick in just about any browser but IE6 and older. But IE6 will resize the body so as to fit the content, even if it has a fixed height of 100%. But it will only do si in strict mode. This is achieved by specifying a doctype. So put a line like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
at the very start of your html document. No tags (not even < ?xml ... ?>) should come before the doctype.

This trick doesn’t work for IE5.5 and older (footer overflows the content), so we have to make sure we make a special rule for them to make it look at least a bit decent.

Footer demo - here is the demo. See the source for more info. It’s commented step by step so I think you should be able to understand what I did.

Yesterday, Apple released it’s Safari 3 beta for OS X and Windows. I’ve been playing with it and it seems quite nice. Windows users did report some problems (and even more problems).

Anyway, I’ve been looking at the web standars project page just now, and noticed the menu looks rather weird in safari. So I’ve investigated a bit and found out it uses text-shadow. So I made a little test case. See how it renders in Safari. Pretty neat, ha? I don’t think any other browser supports this currently. Firefox 2.0.0.4 and Opera 9.00 sure don’t, but I’ll check a few newer versions later today.

update: Opera 9.2 and Firefox 3.0 alpha fail to render text-shadow

update #2: It seems this is old news. text-shadow has been around since safari 1.1 and is said to be working in konqueror also. But what are the big guys (firefox, opera, ie) waiting for?