Body text is often an after-thought in design. We have all been guilty of this at some point in our careers. When you implement your CSS, you might simply throw a body { font-family: blah, blah blah; } into the CSS, and after that you move on. You’ve probably figured out the whole base font size thing too, which can help, but there’s so much more you can do. Let’s look at a number of things to help your body type become something a bit more visually appealing and readable.

Text Color

Hopefully you’ve already figured this one out, but I dare not exclude it for the sake of accuracy. Probably the single most important thing you can do to your body text is change both the color of the text as well as the background color of the area shown behind the text. Here’s a few pointers:

• Readers generally prefer dark text on a light background. There are a few impressive exceptions to this rule, but for the most part, it’s best to stick with the old “dark on light” tried-and-true formula.
• While contrast is important, don’t take it too far. Black text (#000000) on a white background (#ffffff) is perhaps a bit too much contrast. Opting for a slightly lighter shade of text can make it easier on your readers’ eyes. If I’m working on a white background, I generally choose a font color that is at or in the general vicinity of #666666 (don’t be afraid to add a subtle hue of color too, but keep it dark).
• Add some variety by slightly changing the color of elements in your body text like darker <strong> text or lighter <li> items. You don’t have to stick with a single color for all text in the entire design.
• Keep the focus on your article or body text. If you have a sidebar or widgets that appear to the side of your actual body text, try lightening their text color (or reducing contrast with a different background color) to make sure that users focus on the real content of the page.

Font Size

Another obvious and quite important element of your body text style is the font size. There are a number of different ways to establish a default font size for your text. While the method of setting your font sizes is a matter of debate, there are a few best practices you should be aware of.

• It’s easiest on your users to set the body font size at 62.5%, and use ems to size your fonts from there (.wrapper { font-size: 1.3em; } would set the font size to 13 pixels in height).
• Choose a base font size of at least 12 pixels in height. There are exceptions to every rule, but you’ll find that users are frustrated by tiny font sizes, and are apt to leave a site even before using the handy browser zoom feature.
• Deviate from the base font size only where it makes sense in the overall theme of the design. Consistency is key. Set default CSS styles for things like the <small> tag and headers.

Font Family

Fonts are a bit tricky in web design, basically because you’re forced to choose one of about ten fonts that are used on every other website in the world. Typekit is great for header text, but you’re better off using regular web-friendly fonts for your body text. Here’s a few pointers:

• Serif vs. Sans-Serif: First choose the font style you’ll be working with. Choose something that fits with your design’s overall theme or concept. Serif fonts like Times and Georgia give your site a vintage and book-like feel. They are flowing, artistic, and regal in theme. Sans-serif fonts like Arial or Helvetica can be used to portray a clean, professional, and strong atmosphere in your design.
• Choose a common font for your body text that is available on both Mac and PC platforms. There are some great fonts on the Mac, but you’ll want to design your site so that it looks good no matter what device is accessing it.
• It’s completely acceptable to add a “nice to have” font into your design, such as Helvetica or Myriad Pro. These fonts can gracefully degrade to Arial without jarring the layout of your page too much.
• Georgia and Times are not the only serif fonts available! Try experimenting with fonts like Book Antiqua or Platino Linotype, which have a more book-like and artistic feel.
• Courier New is a great fixed-width font best used for displaying CSS, HTML, or some kind of code to your readers.
• Don’t forget other elements in your design! By default, text boxes, buttons, and select menus will not use the body font family and/or size, so make sure to set a consistent font on all elements in your design.
• Don’t use Comic Sans.

Margin, Spacing, and Line Height

This is probably the most overlooked element of body type design. After you’ve developed the character design of your body type, take a step back and examine the paragraph style.

• Unless you specify otherwise, the lines of text in your design are drawn very close together, and it can be difficult for readers to follow as they read down the page. Add a bit of CSS such as p { line-height: 1.5em; } to make this text easier on the eyes.
• Likewise, paragraphs of text have default margins applied to them that may make them appear too close together or too far away from the headers that appear above them. Try adding some CSS such as p { margin: 0 0 1.5em 0; } to standardize the spacing around paragraphs.
• Paragraph text is not the only thing you’ll see in a page. Don’t forget to style other HTML elements like lists (<ul> or <ol>), the horizontal rule (<hr />), and block quotes or call-out boxes.

Be Creative

Following these rules isn’t a guaranteed way to make your body type look amazing, and breaking any or all of these rules certainly doesn’t guarantee that your design will be ugly and fail. In the end, it’s all about being creative and paying attention to all the tiny details that go into making a website look amazing. The difference between a good design and a bad one can be very subtle. Create something fun, stick to a theme, and take note of every visual detail that appears on the page, body type included.

What is input prompt text?

You’re probably familiar with the concept, even if you don’t know what I’m talking about. Here’s an example:

The prompt text appears inside the form field as soon as the page loads, so users immediately know what it’s for. Simple, right?

Why it Doesn’t Work

There are a number of problems you’ll encounter while implementing prompt text into your forms. Watch out for these caveats when you’re developing your own solution.

1. Input validation — if someone submits the form without first removing the prompt text, your prompt text is submitted in lieu of real data. Fixing this is a pain. Avoiding this entirely is recommended.
2. Prompt style — it’s best to style the prompt text so that it doesn’t look like real form data. Creativity is a virtue, but generally web users will expect light (gray) text and italics. This can be problematic because you’ll have to swap the input style back and forth using JavaScript.
3. Losing focus — when users focus on a form field, don’t type anything, and then click somewhere else, you should always add the prompt text back into the input box. Otherwise, users could miss the intent of the form field entirely. Again, you’ll have to do this with JavaScript, which can be a little tricky.
4. Progressive enhancement — always make sure that users without JavaScript can still understand and interact with your form fields. This is progressive enhancement at its finest.

The Solution

Almost everything related to the problems listed above originates from one basic fact: you’re trying to create both a field and a label using a single HTML element. When you take a step back and think about that, it really doesn’t make much sense, does it? The solution lies in separating the form field from the label entirely. We’ll use a little bit of jQuery to create an elegant solution that dynamically creates these labels and places them over our form fields. Because we’re creating two separate elements, we can use CSS to style them independently. Perfect!

The jQuery:

$(document).ready(function(){
  $('input[type=text][title],input[type=password][title],textarea[title]').each(function(i){
    $(this).addClass('input-prompt-' + i);
    var promptSpan = $('<span class="input-prompt"/>');
    $(promptSpan).attr('id', 'input-prompt-' + i);
    $(promptSpan).append($(this).attr('title'));
    $(promptSpan).click(function(){
      $(this).hide();
      $('.' + $(this).attr('id')).focus();
    });
    if($(this).val() != ''){
      $(promptSpan).hide();
    }
    $(this).before(promptSpan);
    $(this).focus(function(){
      $('#input-prompt-' + i).hide();
    });
    $(this).blur(function(){
      if($(this).val() == ''){
        $('#input-prompt-' + i).show();
      }
    });
  });
});

The CSS:

.input-prompt {
  position: absolute;
  font-style: italic;
  color: #aaa;
  margin: 0.2em 0 0 0.5em;
}

The HTML:

<input type="text" title="Enter search keywords..." />

Basically, this script finds any <input> tags that have a title attribute (i.e. <input title="Enter search keywords..." />). For each of these form fields, it takes the title and creates a little <span> tag next to it. The CSS positions the <span> tag so that it appears on top of the form field. The rest is just a little bit of scripting that makes sure to hide and show the labels based on what the user is doing with the input box.

The Result

Here is a demo of the code shown above:

Users without JavaScript enabled will see the normal title tool tips when they hover their mouse cursor over the form field. Please note that you’ll probably have to adjust the margin a bit in the CSS to make sure the labels fit the size of your input boxes. For more information on jQuery and all the great things it can do, visit jQuery.com.

Concerning Accessibility

Accessibility is chiefly important for a web designer (or at least, it should be). When you create your HTML, keep things as simple as possible. Assume that every single user who visits your site will (1) not have CSS support, (2) will disable all images on your page, and (3) will not have JavaScript enabled. If you design your HTML in this fashion, you’ll find that creating accessible content is much easier to do. Once you have an accessible document that works on all systems, you can use the fantastic features of CSS and client-side scripting to really bring your site to life. These “nice to have” features (style, scripting, etc.) are not essential to the structure of your document or the content that’s contained within. When it comes down to it, users are after your content, so that’s priority number one.

A Simple Example

With that in mind, let’s say we wanted to create an image that links to another page (this is so very simple, but it serves as a great example of this technique). Because we’re assuming that users have disabled all images, we certainly don’t want to use the <img/> tag for our link, because those users without image support simply won’t see it. For that reason, our link will look like any other link on the site.

<a class="learnGuitar" href="http://www.mahalo.com/how-to-play-guitar-for-newbies">Learn Guitar</a>

I know…this is really simple, but stay with me; I promise we’re going somewhere with this. Our very simple HTML has passed our criteria: users with CSS disabled will see the link, as will users without images or script. It’s very simply an accessible link on our page, read as easily by normal users as it is by search engines or even people using screen readers. Next, for users who can utilize our “nice to have” features, we’ll add a bit of CSS to make our image appear.

.learnGuitar {
	display: block;
	width: 200px;
	height: 50px;
	background: url('/path/to/learn-guitar.png');
	text-indent: -9999em;
}

As you can see, we’re using the text-indent CSS property to bump our text out of the way, and in it’s place, we’re using background to set an image for our link. All you have to do for your own image is adjust the width, height, and background URL to match. What you get when you’re all done is this:

Learn Guitar

Adding a Hover Image

Easy and accessible CSS image replacement! It looks great, but let’s take it one more level to really make sure users know that our button DESERVES to be clicked. Let’s add a hover style. I’m going to use an image “sprite” for the hover image, which means that both our static and hover states are contained within the same image. Here’s my *single* image that’s used for this type of style:

We’ll adjust our CSS to account for our new hover image. Note that the height and width attributes will not change! The hover-state image will be “clipped,” so that it’s only visible when users move their mouse cursor over our image button.

.learnGuitar {
	display: block;
	width: 200px;
	height: 50px;
	background: url('/path/to/learn-guitar.png') top;
	text-indent: -9999em;
}
.learnGuitar:hover {
	background-position: 0 -50px;
}

Now, when users move their mouse cursor over our image button, the CSS will “slide” the background image so that the hover state is displayed instead of the static state.

Learn Guitar

Crafting your image buttons in this fashion can really save on performance and download times. Perhaps more importantly, your site will be much more “friendly” to visually impaired users using screen readers, and you’ll find that search engines will have an easier time understanding what your links and other content are all about.

Let me know if you have any questions or comments!

Targeting Print Media With CSS

Browsers already have built-in support that allows you to separate your screen media CSS from your print media CSS. By default, when you visit a page, you are going to see the “screen” version of your CSS style sheet, but if you hit the print button in your browser (and if the web designer for that particular site has created print-version CSS styles), you may see an entirely different set of CSS styles that have been optimized for display on paper. Here’s how it’s done:

<style type="text/css">
@media screen {
	body {
		background: #000;
		color: #fff;
	}
}
@media print {
	body {
		background: #fff;
		color: #000;
	}
}
@media screen, print {
	p {
		margin: 0 0 1.5em 0;
	}
}
</style>

In the CSS shown above, we have segregated our CSS into three distinct sections. First, we show the CSS that is to be used only in screen media (@media screen). Next, we designate a block of our CSS to be used only in print media (@media print). Finally, we have a block of CSS that includes styles to be used in both screen and print media (@media screen, print). This allows you to create styles only once if they are the same in both print and screen media.

Font Sizes

In a previous post, I talked about the different font size units and the web. In this post, I concluded that the percent (%) unit is the font size most suitable for internet screen media. Because we are creating a print-version style sheet, however, the percent unit is no longer preferred. When you create a document in a word processor, such as Microsoft Word or iWorks Pages, you choose the font size based off of a unit called “points.” Points are font sizes optimized for printing, so we’ll want to make use of them in our print-media CSS style sheet. Generally, you’ll want to set the base font size on your body tag to 11 or 12 points.

<style type="text/css">
@media screen {
	body {
		font-size: 100%;
	}
}
@media print {
	body {
		font-size: 12pt;
	}
}
</style>

Design Width

Many site designs have a fixed pixel width, which doesn’t translate very well to print media. Some browsers, such as Internet Explorer, will actually shrink your entire design in order to fit everything on the page, but many other browsers will simply clip the contents of your site when printing. Generally, neither of these scenarios are desirable (shrinking your site often makes the font sizes too small). Because you can’t predict the type of printer or the type of media on to which your site is being printed, you should always use a percentage width (preferably 100%) for your site layout. Here’s how:

<style type="text/css">
@media screen {
	.myOuterDiv {
		width: 1000px;
		margin: auto;
	}
}
@media print {
	.myOuterDiv {
		width: 100%;
	}
}
</style>

In this example, visitors to your site would see the myOuterDiv box as 1000 pixels wide (aligned in the center of the screen), but when printing the page, that particular <div/> tag would expand to the full width of the printed media.

Other Considerations

In many cases, you may want to hide something entirely on print media. Navigation, for instance, often serves no purpose on printed media. Search boxes, breadcrumbs, and forms are other examples of elements that you may want to hide when printing. To do this, just add display: none to an element in the print media CSS:

<style type="text/css">
@media screen {
	.topNavDiv {
		font-weight: bold;
		text-align: center;
	}
}
@media print {
	.topNavDiv {
		display: none;
	}
}
</style>

Putting it All Together

I’ve combined all of the elements discussed above into a simple HTML example. Click on the link below to visit a sample HTML page that displays entirely differently on the screen and on print media. You don’t have to print out the page! Just go into your browser’s “Print Preview” function to see the difference.

See the print media style sheet in action

Meet the Units

1. “Ems” (em): The “em” is a scalable unit that is used in web document media. An em is equal to the current font-size, for instance, if the font-size of the document is 12pt, 1em is equal to 12pt. Ems are scalable in nature, so 2em would equal 24pt, .5em would equal 6pt, etc. Ems are becoming increasingly popular in web documents due to scalability and their mobile-device-friendly nature.
2. Pixels (px): Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen). One pixel is equal to one dot on the computer screen (the smallest division of your screen’s resolution). Many web designers use pixel units in web documents in order to produce a pixel-perfect representation of their site as it is rendered in the browser. One problem with the pixel unit is that it does not scale upward for visually-impaired readers or downward to fit mobile devices.
3. Points (pt): Points are traditionally used in print media (anything that is to be printed on paper, etc.). One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and cannot scale in size.
4. Percent (%): The percent unit is much like the “em” unit, save for a few fundamental differences. First and foremost, the current font-size is equal to 100% (i.e. 12pt = 100%). While using the percent unit, your text remains fully scalable for mobile devices and for accessibility.

So, What’s the Difference?

It’s easy to understand the difference between font-size units when you see them in action. Generally, 1em = 12pt = 16px = 100%. When using these font-sizes, let’s see what happens when you increase the base font size (using the body CSS selector) from 100% to 120%.

As you can see, both the em and percent units get larger as the base font-size increases, but pixels and points do not. It can be easy to set an absolute size for your text, but it’s much easier on your visitors to use scalable text that can display on any device or any machine. For this reason, the em and percent units are preferred for web document text.

Em vs. Percent

We’ve decided that point and pixel units are not necessarily best suited for web documents, which leaves us with the em and percent units. In theory, both the em and the percent units are identical, but in application, they actually have a few minor differences that are important to consider.

In the example above, we used the percent unit as our base font-size (on the body tag). If you change your base font-size from percent to ems (i.e. body { font-size: 1em; }), you probably won’t notice a difference. Let’s see what happens when “1em” is our body font-size, and when the client alters the “Text Size” setting of their browser (this is available in some browsers, such as Internet Explorer).

When the client’s browser text size is set to “medium,” there is no difference between ems and percent. When the setting is altered, however, the difference is quite large. On the “Smallest” setting, ems are much smaller than percent, and when on the “Largest” setting, it’s quite the opposite, with ems displaying much larger than percent. While some could argue that the em units are scaling as they are truly intended, in practical application, the em text scales too abruptly, with the smallest text becoming hardly legible on some client machines.

The Verdict

In theory, the em unit is the new and upcoming standard for font sizes on the web, but in practice, the percent unit seems to provide a more consistent and accessible display for users. When client settings have changed, percent text scales at a reasonable rate, allowing designers to preserve readability, accessibility, and visual design.

The winner: percent (%).

Addendum (January 2011)

It’s been a couple years since I wrote this post, and I’d like to sum up the discussion and debate that has happened in that time. Generally, when I create a new design, I will use percent on the body element (body { font-size: 62.5%; }), and then use the em unit to size it from there. As long as the body is set using the percent unit, you may choose to use either percent or ems on any other CSS rules and selectors and still retain the benefits of using percent as your base font size. Over the past couple of years, this has really become the standard in design.

Pixels are now considered acceptable font size units (users can use the browser’s “zoom” feature to read smaller text), although they are starting to cause some issues as a result of mobile devices with very high density screens (some Android and iPhone devices have upwards of 200 to 300 pixels per inch, making your 11- and 12-pixel fonts very difficult to see!). As a result, I will continue to use percent as my base font size in web documents. As always, discussion and debate is encouraged and welcome; thanks for all the great comments over the course of the past two years!