Half way through the presentation, I switched gears and announced we’d be converting a real-world example from tables and spacer gifs to a pure CSS layout. I could have created a fictitious example to work with in the presentation. But that idea would have seemed too contrived. If I created my own example, it would have been nice and tidy. Everything would have rendered exactly as I wanted it to, staying free and clear of any “trouble spots” I already knew to avoid.

Fictitious wasn’t good enough. I wanted a real challenge. So I chose the site of a small, local-to-the-Seattle-area company I thought a few of the attendees in the audience might be familiar with: Microsoft

Ok, maybe more than just a few attendees were familiar with this not-so-small company. Many users arrive at Microsoft’s home page every day. Microsoft’s literal home page may or may not be as well-known and oft-used as search giants Google and Yahoo! But microsoft.com in general gets tons of traffic, and the people which pass through its domain every day quite likely number in the millions.

The shame is that Microsoft’s site isn’t as optimized as it could be. They haven’t taken the plunge yet. Users download unnecessarily larger pages, and servers waste extra bandwidth to keep up. At 40 KB, the HTML for Microsoft’s home page is not exactly a bloated beast. But it is burdened with inaccessible, kludgy, table-based markup filled with proprietary attributes and some awkward JavaScript. Notice I didn’t mention whether it was valid markup or not. Despite using the flavor of XHTML, Microsoft omits the doctype on their home page.

Why Microsoft?

Is this just another “pick on Microsoft” thing?

Bluntly and honestly… no.

I didn’t choose Microsoft to jump on the bashing bandwagon, or to toss a few more pot shots at a company some people in our industry love to hate. (I didn’t pass up any opportunities to question certain decisions they’ve made, but I avoided passing judgment.)

I admit that I purposely chose and targeted a high-profile company. It’s my nature to go after the top guns. But it’s also an example with which almost everyone is already familiar. Microsoft.com was (and is) a perfect candidate for a standards-compliant CSS makeover.

Here’s why…

Reason #1

Because of the inefficient use of an abundance of tables and spacer gifs used to layout the page. Pages are more locked down when their content is laid out using tables, and can often be less accessible as a result. Microsoft is not alone here. An overwhelming majority of sites on the Web today still use lots of tables for page layout and other purely visual purposes. I chose Microsoft because it could serve as a well-known example (and eventually a model) that relates to the same issues many sites still need to address.

Reason #2

Because the basic structure of Microsoft’s current design is a model that thousands of websites use for their own site design: Header + 3 columns + Footer. Specifically: a Header that spans all the way across the top of the page, a Left column containing mostly navigation, a Main column for content, a Right column for extra “stuff”, and a Footer that sits below all three columns and also spans the entire width of the page. If it’s not a 3-column layout, many sites might use a 2-column variation of this same basic structure with a Sidebar to the left or right of the Main column:

Reason #3

Because Microsoft’s home page uses CSS for little more than FAC (fonts and color). I’d love to see the company that basically invented the concept of style sheets in an application environment, lean more heavily on CSS, and less on old-school methods.

Reason #4

Because Microsoft is currently serving a different version of their home page depending on which browser is used to view it. One version for Internet Explorer for Windows (v5.5 and above). Another somewhat “dumbed-down” version for all other browsers (including IE/Mac) that omits some of the imagery and all product logos. The non-IE/Win version leaves out some of the functionality (e.g. fly-out menus) and renders page elements with different techniques. If you have IE/Win 5.5 or higher, plus another browser available, you can check for yourself. If not, here’s a screenshot of the two versions, with differences circled in red:

The non-IE/Win version is noticeably more anemic than the full version served to IE/Win. We all know it doesn’t need to be this way. If you’re wondering, it’s not just sloppy coding that works in some browsers and not in others. Microsoft intentionally does a JavaScript browser detect, and redirects the browser to a different file if the browser is IE5.5 or higher. Instead, Microsoft could just maintain one version that works in all browsers.

At least Microsoft serves a version of its page to non-IE/Win browsers. Some developers may not even go that far. The frequent reason we hear cited for dropping support for other browsers is that MSIE/Win is THE browser used by a MAJORITY of people, and that it takes TOO LONG to develop for (and render properly in) any other browsers. Others complain that development for browsers other than IE/Win is TOO EXPENSIVE. Both the too long and too expensive claims are false.

Many developers believe these claims because they start by developing for — and checking in — IE. Then they view it in another browser and become frustrated when they see all kinds of supposed “bugs” they think they’ll have to fix.

IE interprets CSS more loosely than other browsers that have been iterating versions over the last couple years (Mozilla, Firefox, Safari, Opera…). Starting with IE means fewer problems with development work will be detected early on. Developing for IE initially, then trying to retrofit for other browsers will increase time and cost in the long run. But there’s a better way to approach development that’s faster and less costly.

Start with the stricter, more compliant browsers that (usually) render things how they’re supposed to render. Get everything working there. Then, double back and create a few “patches” for IE. Development is much faster this way. It may be counter-intuitive to initially avoid the browser that represents the majority of your traffic. But the process is much more fluid and efficient if you don’t become accustomed to — or depend on — IE’s relaxed rendering behavior. Start with IE, and you may start with bad code that takes much longer to fix for other stricter browsers.

Going this route, we still have the IE Factor to contend with. However, as we gain more experience with IE’s CSS misbehavior, the IE Factor eventually starts to minimize. There is hope.

Just the Facts, Please

For the second half of the presentation, we stepped through the entire process of converting Microsoft’s table-based spacer-gif-laden page to a more accessible, purely CSS-driven version that works in all browsers. This is not new. Others have re-coded microsoft.com before. Many regular readers of this site have been creating tableless designs for a year or more by now. But we don’t see everyone else jumping into the water yet, despite the water being fairly thoroughly tested by now. Thus, the presentation at Digital Design World, and this follow-up article.

Continuing the presentation, we broke down each stage of the process into manageable chunks. I highlighted each of the major steps of the process, including the dumping of tables, conversion to more semantic markup, and the CSS techniques used to faithfully reproduce each portion of Microsoft’s home page design.

Throughout the presentation, we examined lots of visuals (diagrams, screenshots, and pictograms) that aided in understanding the techniques used to render each section. I also had the code saved out as separate “pre-baked” files I could refer to for each stage of the process.

One of the reasons for writing this follow-up article is to publish the final results of the Microsoft.com makeover, which are kind of hard to ignore:

Going Further

The numbers get even more interesting when we start doing Meyer/Davidson ESPN-style estimates and projections. According to a public Microsoft page titled “Inside Microsoft“, Microsoft’s published traffic numbers state that microsoft.com got 1.2 billion page views during the month of May 2004. In this presentation, I showed how to decrease the markup from one page by 62%, or 25 KB. I also predicted that about 25 KB is a fair savings estimate per page if Microsoft was to get more aggressive about using CSS site-wide. If multiplied out by an average of 38.7 million page views per day, that 25 KB savings per page could add up to about 924 GB in bandwidth savings per day, or 329 terabytes per year.

These numbers alone should be enough to turn a few heads.

Now, toss in the fact that the makeover is just one version, and supports Microsoft’s more “advanced” design, (as currently seen in IE/Win) and does so in many more modern browsers.

Companies like Microsoft may or may not want to maintain just one version of their home page that works in more browsers, loads faster, and is more accessible to all kinds of users and devices. Regardless, I thought it was worth pointing out that it’s now very possible to demonstrate and walk through how they — or any company — could create one super-powered version that uses leaner markup, works in more browsers, and increases accessibility. All demonstrated within the time span of an hour or two…

Additional Points and Caveats

• If you’re curious, and like to be thorough, the CSS only increased from 3 KB and 5 KB (IE/Win and non-IE/Win versions, respectively) to 8 KB for the makeover version.
• The fly-out menus seen in IE/Win’s version for two options in the left-side navigation are possible to reproduce as well. All done with pure CSS and simple, semantic, accessible markup. The makeover uses the :hover pseudo-class to toggle on/off a nested unordered list when mousing over the parent list item. One consideration: IE doesn’t support :hover on list items, so the JavaScript method Microsoft is already using would still be necessary to support fly-out menus in that browser. Or something like Suckerfish Dropdowns could be used to keep the same semantic nested-list markup the makeover version uses.
• The hefty jump in number of image tags for Microsoft’s current non-IE/Win version is due to heavier spacer-gif usage. The non-IE/Win version also calls every bullet image individually, rather than via one CSS declaration, as the IE/Win and makeover versions do.
• All of the JavaScript found in Microsoft’s markup was removed. As were hundreds of proprietary attributes in anchor elements that were/are apparently used for click-tracking purposes. Microsoft would likely want to add some of this layer back in — though hopefully through a valid means of doing so.
• As mentioned above, the point of this article is to publish the potential results and benefits of using CSS and simpler, more semantic markup to build pages. It merely uses Microsoft as a well-known example. This article intentionally omits linking to the final makeover code. I understand that many people could learn from the work done for this presentation, without seeing the presentation, by studying the changes made to the HTML and CSS. However, I do not want to downplay anyone’s role at Microsoft by publicly releasing modifications to their source code before having a chance to present them directly to Microsoft, and discuss the changes and techniques with appropriate team members, if they ever wish to do so.

Translations

This article is translated into the following languages:

• Brazilian Portuguese: Jogando as Tabelas Pela Janela by Humberto Oliveira
• Simplified Chinese: Throwing Tables Out the Window by Gregory Song
• Dutch: Tabellen uit het raam gooien by Nick Verstappen
• French: Passer les tableaux par la fenêtre by Benjamin David
• German: Tabellen aus dem Fenster werfen by Eric Eggert
• Italian: Gettare le tabelle fuori dalla finestra by Giuseppe Di Carlo
• Japanese: Throwing Tables Out the Window by Kohei Yoshino
• Polish: Wyrzucanie tabel przez okno by Pawel Grzesiak
• Spanish: Tirando las tablas por la ventana by Hermann Kaser
• Turkish: Tablolari Pencereden Disari Atmak by Mehmet Dogan

Update: As of 27 July 2005, the example code and corresponding presentation slides were released and made available to everyone. See Still throwing tables for background information and links to the code and presentation referenced in this article.

With an understanding of the technique firmly in grasp, now we can push it further. ALA just published Sliding Doors of CSS, Part II, which expands on what we covered the first article (Part I). Specifically, Part II addresses:

• Scenarios where no tab is highlighted
• Combination with Pixy’s single-image no-preload rollover
• A fix for IE/Win’s limited clickable region
• An alternate method for targeting the current tab
• Additional notes and uses for the technique

Part II fills in some gaps and expands on the utility and behavior of the original technique. If you haven’t yet read Part I, I highly recommend you do so before reading Part II. Again, instead of opening up comments here, I’ll direct any feedback you might have to the discussion on Part II already open at ALA.

(Translated into: French I, French II, Italian, Russian)

Read the full article at A List Apart.

If you happen to speak or understand French better than English, I’ll point you to a new translation of this article at Pompage.net: Les coulisses d’un design. Thanks to Stéphane Deschamps who did the translation after asking permission. Unfortunately, I speak very little French (pero hablo español mucho más). But since I wrote the original version, I can at least follow along every ten words or so.

“I’m puzzling over why with the main nav bar you nested an absolute div into a relative div?”

A simple answer to his question is: Because I wanted optimum flexibility for the header and navigation, and to keep the navigation the same distance from the logo, no matter how the text is resized.

That’s the strategic answer providing rationale for the method. But I gather he might also be seeking a tactical answer. To answer his question thoroughly, I’ll backpedal a bit, and explain the workings of CSS absolute positioning in my own words, provide an example which demonstrates a different effect than the one achieved in the Adaptive Path design, then come back to the AP navigation.

Containing Blocks (Positioning Context)

Nesting an absolute-positioned element within a relative-positioned element is a fairly oft-used technique. More commonly, one may hear the inverse stated: a relative-positioned element is wrapped around an absolute-positioned element.

According to the CSS2 spec, an absolute-positioned element is positioned according to its containing block. Any element is considered “positioned” if it has a position value of relative, absolute, or fixed (anything other than static). “Static” is one of the possible values for the position property. It’s also the default value for any element if no other position is specified. Static basically means an element’s position is not modified, and the element will appear in the expected normal flow of the document in context with other sibling elements and containing blocks.

If an absolute-positioned element resides within no other containing block, (when no ancestor elements are positioned) it is placed relative to the page boundaries (called the initial containing block). Thus, an element styled with the following rule:

#topleft {
  position:absolute;
  top:0;
  left:0;
  }

will get placed in the top-left corner of the page. However, any positioned ancestor establishes a new containing block for all its descendant elements. If an ancestor element gets positioned, the positioning context of any descendant element is reset to the boundaries of that ancestor element (the new containing block). Thus, the box offsets in the rule above would position the #topleft element at the top-left corner of the positioned ancestor, rather than the top-left corner of the page.

Lost yet? It still sounds like gibberish to me too. I’ll pull up a common example to help drive it home.

Dynamic Positioning

For stopdesign.com, (at the time of this writing) I use absolute positioning for the right column (#subcol). When I designed the templates, I wanted the right column to appear immediately below the header (#header) with no overlap and no gaps between each block. The header contains the logo and main navigation. Because the navigation is text, it can be resized via browser controls. This directly affects the height of the entire header. I could have positioned the right column in context to page boundaries, choosing a starting top position based on a measured header height. But since the header varies in height from browser to browser based on default text sizes, this means the right column would sometimes overlap the header if the header grows in height. Or a gap may appear between the header and right column if the header gets smaller than my initial measurement.

Diagram 1

To adapt to this variable header height, I use a positioned container element (#content). This container appears in the markup immediately after the header, and is assigned position:relative;. This allows the container element to appear in (and affect) the normal flow of the document; the top of the container will always appear immediately below the bottom of the header, no matter how large or small the header becomes. Because #content is positioned, this also resets the positioning context for any elements it contains. The right column (#subcol) is contained within #content, so the right column gets positioned in the top-right corner of #content, rather than the top-right corner of the page. This allows the right column to adapt in vertical position according to the height of the header, as modeled in Diagram 1.

Bottom-hugging Navigation

Diagram 2-A

Diagram 2-B

Finally, I circle back to the Adaptive Path navigation, which represents a different use of this making-absolute-relative technique. I could have easily assigned a fixed margin-top to the navigation and been done with it. But in this case, I want the header to always remain the same height, no matter how large or small the navigation text becomes. In other words, I don’t want the dark green border below the navigation to change in vertical position, relative to the logo, as shown in Diagrams 2-A and 2-B.

Rather, the navigation text is free to be sized up or down, but its baseline position remains constant. It always touches the dark green border, and never overlaps this border. By positioning the #nav element using position:relative; and assigning a specific height to this container (72px), the container establishes a new positioning context for the “inner” div. The inner div can now be absolute-positioned to the bottom of the #nav container using bottom:0;.

Other uses for this technique certainly exist. It’s not an uncommon desire to want to reset positioning context for an absolute-positioned element to something other than the page’s boundaries. The reasoning behind why I do what I do is often obvious to me. But it took a reminder that reasoning isn’t always so obvious to everyone else. Perhaps this technique is now a little more understood by others (maybe even obvious to them) as well.

Translations

This article is translated into the following languages:

• Brazilian Portuguese:
  Posicionando relativamente o absoluto
  by Mauricio Samy Silva

As I mentioned in a related log entry about my CSS Zen Garden submission, I thought it might be interesting to share the process I went through to create the design I titled Golden Mean. Designing one page for the Garden wasn’t a full-scale project, and definitely not done for a discerning client under contract or any type of compensation agreement. But about halfway through the creation of the piece, I noticed I was following a traditional (albeit somewhat condensed) process often used for larger projects. My process, specific to the Garden project, can be grouped into the following phases:

Research & Discovery

Jumping into any design project before examining the problem or task at hand might spin the wheels, but won’t get you very far. Any project, no matter how big or small, can benefit from research and planning before the work begins. Design is no exception. If discovery begins before the exploration commences, the probability of finding a successful direction for the project only increases. The amount of time spent on this phase is usually proportional to the overall scope and planned duration of the project.

For the Garden design, I began by studying the content (text) of the existing page, making a model in my head of the document flow and hierarchy. I aggregated the sections of the page into logical groupings and assigned each a priority. I also spent time thinking about the purpose of the project, along with the ideas and concepts Dave Shea was trying to communicate when he created the Garden space and opened it up for other designers to contribute. Showing off advanced CSS trickery is not the goal of this project. Instead, it attempts to demonstrate the beauty and flexibility achievable when designers grasp all the potential of CSS, using it as a tool to create a well-designed aesthetically-pleasing page which remains accessible, well-structured, and efficiently coded.

Competitive Analysis

Another helpful task in the process involves looking at pre-existing ideas and executions created by peers, mentors, heros, and/or competitors. Competitive analysis identifies the strengths and weaknesses of those existing designs. It can reveal gaps which still need to be filled and shortcomings which should be met. The ability to study what others have designed for the same (or similar) problem lends a sizeable advantage, since a great deal can be learned from their successes and failures.

When I finally came across free time to start thinking about one of my own submissions, I had the advantage of being able to study many submissions which already resided in the Garden. I studied the concept and execution of each piece. I admired the cleverness and creativity of some of the existing designs. I noted similarities and differences between all of them. I sought out the characteristics which weren’t yet present.

Exploration

When tackling a design project with limitless creative boundaries, I like to begin by creating lists of relevant words, topics, and phrases. Sort of a free-form brainstorming of thoughts related to the project at hand. Some are abstract and loose, some are concrete and tightly related. By creating these lists, I try to gain a broadened perspective of the problem I’m attempting to solve, and often uncover additional ideas and concepts which weren’t so obvious at the outset. My Garden lists contained groupings of words and thoughts related to gardening, plants and flowers found in a garden, zen-like qualities, beauty and beautiful things, and characteristics of page design. I also created lists of all the elements, IDs, and classes used in Dave’s HTML, some of which made subtle appearances in the final design.

Thumbnail Sketching

Once I exhausted the idea branching, I started drawing thumbnail sketches [.gif, 46 KB] on a pad of paper. Thumbnails are small sketches which can literally be as small as your thumbnail, or as big as a couple inches in width and/or height. Think of the kind of drawing that might be seen on a cocktail napkin. Thumbnails are intended to capture the basic ideas for page composition, like header placement, column structure, and text alignment without allowing the temptation to focus on small details too early in the process. They can be quickly sketched allowing rapid idea iteration. Don’t like the one that just took 30 seconds to draw? Start another one right beside it. To keep them general, it’s best to start with rather small sketches. Then slowly size them up as more details need to be worked out.

Typography

Once I had a few rough compositions I liked, I began studying typefaces and letterforms. To me, typography is a crucial element in setting the formalness or informality of a design. Evocations of different typefaces are subliminal to most people, but a designer will go to great lengths to ensure the selection and construction of type complements the mood of the piece. The easiest way to examine the effect of different typefaces for this project was to create an Illustrator file, and begin setting “CSS Zen Garden” and “The Beauty of CSS Design” in multiple fonts [.gif, 28 KB]. I had an idea of what I wanted. I also have a rather high familiarity with lots of typefaces. But I wanted to explore all the possibilities. I was looking for something I thought characterized clever design. Something fun or unique which played to the ideas beginning to form in my head.

I selected the final typeface — Morpheus — because of its beautiful letterforms [.gif, 18 KB]. The uniqueness of the M and N, the gothic arches of the A and U, the extensions of the K and R, the way specific letters intimately replicate numerical forms like the S and lower-case d, the decorative diamond which dots the lower-case i and graces the bowls of rounded letters such as the D, O, and Q. In addition to my affinity for the letterforms, the pronounced medieval style of the headline type created a perfect contrast with the sans-serif modernity of supporting keywords and titles which I set in Helvetica.

Imagery

Imagery is not always necessary in design. In fact, some of the most beautiful designs use type alone. However, selectively chosen photography or illustration can create enormous visual impact for a design, adding dimension, implication, and a deeper level of understanding far beyond a well-written headline or paragraph of text.

My next step in the process was to research imagery which could be used as the foundation for background texture, and act as supporting visual content. The lists I created earlier in the Exploration phase helped provide direction and spawned additional ideas. After searching though my own stockpiles of digital photos and artwork, and a few external resources of royalty-free images, I selected several potential pieces which already possessed some of the layering I wanted to include in the artwork for the page. I chose to use a manipulated image of a daisy [© Copyright 2003 by Lee Pettet] as the base art for this Garden design.

I’ve long been a fan of layering type for the purposes of creating texture and added relevance. I also like combining text and imagery to achieve subtle variations in color and value. (For historical examples, see relevant portfolio pieces: 01, 02, 03). Just as with other pieces I’ve created, I built up the Garden type over time, taking it through a deliberate process of addition, subtraction, and manipulation.

Composition

I tend to keep imagery confined to a particular region of the layout, or reserve it for a specific purpose. In my opinion, the overuse of photography or illustration can quickly create a crowded, chaotic design which just obscures the intention or message of the piece. Contrast is an element of design which I love to work with when creating anything visual. This comes just as much into play with use of imagery in a composition as it does within the image itself. Effectively integrating imagery into a design requires an awareness of balance and tension. Compact areas of motion and activity, countered with spaces for the eye to rest and relax.

With a few rough comp ideas sketched out, and initial choices for typeface and imagery made, I began combining them in more developed digital sketches. Flipping back and forth between Illustrator and Photoshop, importing art from one into the other, the design was pushed closer and closer to it’s final mocked-up state. When designing outside HTML and CSS, I focus on constructing the language and guidelines of the page, determining proportions, widths and heights, gutters and white space, specifying complementing typefaces, choosing relative type size and leading, and the application of color as a means of both obvious and subtle accent.

Execution & Implementation

I’ve already covered some of the issues I encountered when constructing the CSS for this Garden submission. (See the related log entry for details.) I started writing the CSS for the design at a high-level, focusing on the layout structure, major backgrounds, and large regions of the page. Groups of elements were positioned in correct locations. Then I applied the necessary detail to each element, from the top of the page, down.

As I composed the style sheet and tested the page in various browsers, the design changed in small ways. Some changes were sacrifices. Some were evolved improvements. The addition of a background pattern to the left and right of the primary image was an added benefit of discovering I couldn’t position the header as I originally intended. The vertical alignment wasn’t refined until after each column was already positioned on the page. (The left and right columns were originally staggered in vertical starting position.)

These changes were possible because I, as the designer and style sheet author, could make decisions on the fly about what was important to recreate exactly, what could bend a little, and where the flexibility existed for the design to evolve as it was coded. This unity of thought at the final stage of the process is a strong reason the designer and person responsible for generating the HTML and/or CSS need should be working together as closely as possible, if the two are not already the same person.

And More

Although this is where I stopped for the CSS Zen Garden submission, the ever-changing design process does not end here. This summary is not an exhaustive one. Additional review and approval cycles, more design iterations, and frequent user testing all may be inserted anywhere into this process. It’s not always predictable, and may not always function like clockwork. But unless a designer is working for an illusionist, design is certainly not a magical combination of smoke and mirrors either. Maybe just a sleight-of-hand now and then.

Note: This article also exists in French at Pompage.net, translated (with permission) by Stéphane Deschamps: Les coulisses d’un design.

This tutorial assumes a base-level knowledge of CSS, but not much more. Beyond that, it also assumes care will be taken to use these methods fairly and responsibly with well-structured markup.

Introduction

Do you still crave the typographic control of creating headlines and decorative type with images instead of pure HTML text? Even with all the options we have for styling text with CSS, sometimes there’s just nothing that beats the indulgence of opening up Adobe Photoshop, then setting type in your favorite font at just the right size, kerning, and tracking. You know if you save it as an image and place it on a webpage, anyone with an image-enabled browser will see your typographic mastery just as you intended. Right?

But we’ve been beaten over the head so many times with preaching that claims using images for Web type will send us sliding straight to hell. So much so, we’ve dropped our visual standards and given up on the idea that type on the Web can ever be beautiful again. That is, until CSS font downloading is perfected and reliable many years from now.

We’ve been taught images aren’t as accessible as pure marked-up HTML text. This is especially true for assistive browsing software and small-screen devices. So we feel guilty using images for type. Images don’t show up in text-only browsers like Lynx, nor in browsers where users disable image rendering. Even if we’re responsible, always including equivalent alt attributes for each image tag, search robots often index meta data (like alt and title) differently than pure HTML text. This is understandable if we consider the logical importance of heading text when it’s appropriately marked up inside <hn></hn> tags. We won’t even touch on file size problems and download times caused by excessive image use.

Let’s put all that knowledge on hold for a moment. Images aren’t that bad, are they? With a few simple style tricks and a little cautious planning and testing, type on the Web can be guiltlessly beautiful and equally accessible (see notes below) and perfectly indexable, all at the same time. It’s time to spread those wings again.

The Concept

In principle, the concept is very simple. We write a short string of text (eg. “Hello world!”) and surround it with two sets of basic HTML tags. Then we use CSS to hide the HTML text and display a background image containing the exact same words instead of the original text. That’s it. Replacing text with an image is no more complicated than this.

Before we write any CSS, let’s start with some basic markup. Imagine we have a simple HTML snippet like the following:

<div>
  <span>Hello world!</span>
</div>

Of course we could apply style directly to that text. But we want more drama and finesse than any font-family or text-transform property can ever bring us. We want flourish. After all, if we’re saying “Hello!” to the world, we might as well do it with panache, right?

We pick out the perfect typeface for our worldly salutation: Shelley Allegro. A well-known script face in the design world, we discover Shelley has just the right flair to win the hearts of millions as we say Hello. We guess this font may only be available on 1.65% of the computer systems out there. So we take the time to create an image representing the same Hello message. The image will display our message in Shelley Allegro in every image-enabled browser, regardless of whether the font is installed on that system:

We take note of the image height, (35 pixels) since it will be useful a bit later.

So we have some HTML, a glorious text message, and one extraneous image. What do we do with them? Let’s roll up our sleeves and use a little style to replace the text with our new image.

Fahrner Image Replacement (FIR)

This method for replacing text with an image is named for Todd Fahrner, one of the persons originally credited with the idea. You may wonder why there are two sets of tags surrounding our Hello message in the HTML above. A div and a span. Technically the two tags could be anything. In fact, your custom solution may require something a bit more semantic. But we’ll choose these two generic wrappers for this example.

The CSS which executes the swap consists of two simple rules. The first uses background properties to pull our image into the background of the div:

div {
  background-image:url("hello_world.gif");
  background-repeat:no-repeat;
  height:35px;
  }

Note the height property in that rule. It matches the actual height of our image, ensuring the div is tall enough to display all of our image, yet takes up no more height than necessary. The background-repeat property ensures the image only appears once, instead of tiling across the width of our browser window.

The only remaining task is hiding the raw text which we left in our HTML. This is where span comes in. We need a second element so we can address it separately. Hiding the text is easy:

span {display:none;}

Combine those two rules with the HTML we wrote earlier, and we end up with a simple example. So simple, we wonder why it’s taken all this text so far to explain it?

Of course, we’d never leave our markup that simple. Nor would we likely be able to continue using such elementary style rules. Otherwise, every div we use would contain our “Hello world!” background image, and anything we place inside <span></span> tags would magically disappear.

Let’s move on to a few real-world examples.

Example 1: Page Titles

One example of text-replacement is readily available on many of the main pages of stopdesign.com. Notice the primary titles for each section or page (ie.: the words “Recent Log Entries” on the front page) They aren’t created by clever font-styling rules in the CSS. Those are images. Lovingly crafted to match the typeface of the logo. Matted to appropriate colors matching the background on which each is placed. It’s a subtle effect, but one that’s part of this site’s identity.

If we view the source, or toggle the CSS off, we see the title image is not part of the markup for that page. In fact, where most of us probably see an image, the markup uses simple <h1>‘s and pure HTML text to label that page and proclaim the title’s prominence and hierarchy in the document structure.

Screen readers, small-screen devices, and indexing robots will should* ignore any screen stylesheets, getting the pure text marked up as a simple <h1>.

One method of matching images to specific pages is to base the title image on the section in which it lives. Each body could be given an id or class unique to that section. Through the use of descendant selectors, each <h1> could be tied to an appropriate image based on the class of the body that contains it. But each section may contain more than one type of page, and we may want a more appropriate title for subpages of each section.

Instead, it may be wiser to assign each title a unique id matching or abbreviating the words it represents. For example, the Recent Log Entries title on stopdesign’s front page is assigned an id of “t-reclog“. The “t-” prefix is added to help create values which won’t be accidentally repeated in other element id values. “t-” always stands for title in this case. This id makes the markup a little redundant, but allows for the greatest flexibility in assigning any title image to any page.

Each replaced title needs a couple simple style properties assigned to it which are common to all replaced titles. In addition to the id, each title which needs to be “swapped” with an image is given a class of “swap“. The swap class exists so the same properties can be applied to all replaced titles without having to repeat those common properties in every unique title id rule. Alternatively, it avoids the need to specify every unique id appearing throughout the site just to create one rule of common properties. The application of the swap class ensures only those <h1>‘s possessing class="swap" get setup for replacement. Other non-replaced <h1>‘s can exist elsewhere on the site without needing to create rules which override the swap rules. The class addition is a small sacrifice in markup purity for huge simplification gains in the CSS.

For replaced titles on stopdesign.com, the common CSS looks like:

h1.swap {
  height:22px;
  background-repeat:no-repeat;
  }
h1.swap span {display:none;}

And unique id rules look like:

h1#t-recentlog {background-image:url("/img/title_reclog.gif");}
h1#t-articles {background-image:url("/img/title_articles.gif");}
h1#t-portfolio {background-image:url("/img/title_port.gif");}

For ease of editing and maintenance, all page title rules are were separated into a separate titles.css file, which is imported by a linked master screen.css file.

Example 2: Controlled Drop Caps

Ever wanted a special drop cap to decorate the first letter of a paragraph? Yet didn’t like the clunky form created by bumping that HTML letter up to 500% of normal font-size? What about using an image instead? Of course we wouldn’t want to change the way that paragraph were read or presented should the image not be displayed. If we employ a slight variation of the replace method demonstrated above, we can use almost any type of drop cap desired. For example, let’s once again call on our familiar typeface, Shelley Allegro, to create an “E” which starts this same paragraph:

We won’t want the first letter of the paragraph to be separated on its own line (as a div would do). In fact, let’s say we want absolutely no special emphasis to be added when stylesheets are not used to view or read this paragraph. In this case, we’ll use two sets of generic span‘s to markup the first letter of our paragraph:

<p><span class="dropcap"><span>E</span></span>ver wanted a ...

Remember the outer element is what we use to apply the background image. The inner element is what we use to hide the raw HTML text. In this example, we’ll also be floating the outer element so the rest of the paragraph wraps around our drop cap. We’ll also set the display property to “block” to ensure compatibility with the widest range of browsers (even though use of float should do this automatically). We create the following CSS:

span.dropcap {
  display:block;
  float:left;
  width:46px;
  height:63px;
  margin-right:5px;
  background-image:url("dropcap_e.gif");
  background-repeat:no-repeat;
  }
span.dropcap span {display:none;}

The width and height in the first rule above are taken from the image dimensions. We’ve also applied a small right-side margin to pad our drop cap image. Combine the HTML and CSS, apply a small amount of style to the paragraph itself, and we have a simple drop cap example.

More Examples

Creative uses for text replacement are only limited by our imagination. Other possibilities might include:

• Type-based logos and names
• Site headers
• Pull-quotes
• Single-word substitution for cosmetic effect (like “and” or “vs.”)

The method may also be useful for changing themes with alternate stylesheets. Just as you could change colors and styling, an entirely different image could be used for each theme.

Responsible Replacement

This replacement method needs to be exercised with a certain amount of responsibility. Care should be taken in matching the text of each replacing image with the same raw text in the HTML. Otherwise, it wouldn’t be fair to give visitors seeing full-blown stylesheets different textual content than visitors seeing, hearing, or feeling content without the same stylesheet applied. The replacing image can alter type characteristics such as size, color, capitalization, or tightened word-spacing. But those stylistic decisions are made as part of the design process, and should not be applied to the HTML text itself. For example, sandwiching words together (removal of word-spacing, as in the stopdesign.com title images) in the HTML would create unreadable gibberish for screen readers and braille clients. Thus, the HTML text should be spaced, capitalized, and spelled appropriately as if it were completely unstyled in the first place.

Several very important caveats and disadvantages of this method need to be mentioned:

First, although the method is better [than only including raw images] for search indexing robots, it hinders the ability to find the replaced text on the page when the user executes a “Find on this page” search, or when the user attempts to copy and paste the text.

Second, although it may be rare that images are disabled in a browser, but CSS remains enabled, in these cases, CSS will still hide the text, yet may be unable to display the images, resulting in an unintended blank space with no text showing at all. As stated, these cases should be rare: when one is disabled or not available, the other is often the same.

Third, image text is not overridable by the user: they will not be able to resize the text, nor alter its color or contrast to make it more legible (as is possible with raw text).

These disadvantages need to be carefully considered in determining if this method is acceptable in specific instances. If this method is employed, the caveats should also be taken into consideration as the images used are being designed. Small or low-contrast text within the image would be irresponsible. Color-blindness may be a huge issue to consider when choosing colors and values for the text and/or background.

And remember, too much (or incorrect use) of a good thing can always come back to bite and betray. When we experiment with this method, we use it sparingly and with much caution.

Browser Compatibility

Mac: Camino .7+, IE 5+, Mozilla, Netscape 6+, OmniWeb 4+, Opera 5+, Safari

Win: Firebird .6+, IE 5+, Mozilla, Netscape 6+, Opera 5+, Phoenix .5+

Important Notes

This method has been tested and proven to fail in several popular screen readers. See Joe Clark’s well-researched, thoughtfully-written piece at A List Apart: Facts and Opinion About Fahrner Image Replacement.

The findings Joe presents in his article obviously defeat the original intentions of the method itself: creation of a more flexible and accessible solution than a simple <img> with alt text. The flaw with this method is that it assumes text hidden using display:none gets hidden in visual browsers, but will still get read aloud by a screen reader. This is not the case in several screen readers, even if we specify the “screen” media type for our style sheet. Screen readers also pay attention to the screen media type, since they literally read from what’s displayed on screen. Most screen readers don’t support the “aural” media type, so there’s no benefit to specifying speak properties in an aural style sheet.

Some have suggested the use of visibility:hidden; instead of display:none;, but this also prevents the text from being read in most of the same screen readers. Current versions of JAWS — arguably the most widely used screen reader — will read text hidden with FIR. But judging from behavior of other screen readers, we should not rely on this being the case with future versions of JAWS.

As is true with any content-altering technique, the advantages and disadvantages should be carefully considered for each unique case before being implemented. Since this article was written, several alternative methods have surfaced, each with their own advantages. However, no methods have emerged as the “Holy Grail” of text/image replacement. Existing alternatives to FIR are listed below:

Leahy/Langridge Image Replacement (LIR)

This method eliminates the span by setting height of the parent element to 0 and overflow to hidden, which hides the text. Then it uses top padding to force the element to the height of the image in the background. Conceived at similar times by Seamus Leahy and Stuart Langridge.

Rundle’s Text-Indent Method

Mike Rundle devised a simple method of using the CSS text-indent property to shift contained text outside the visible element window.

Cover-up Method

Another method devised by both Petr Stanicek (a.k.a. “Pixy”) and Tom Gilder uses an empty span element to position a background image on top of the text, allowing the text to show up when images are turned off (or don’t load) in the browser.

For further reading on the subject of FIR, refer to the previously mentioned article, Facts and Opinion About Fahrner Image Replacement, and Dave Shea’s In Defense of Fahrner Image Replacement at Digital Web.

I was a die-hard Mac fanatic. One of those arrogant designers who shrugged off Microsoft’s market share and expected 76% of the computing world to revolve around my operating system of choice. If you weren’t on Mac, you didn’t matter.

The legacy goes back to a 1 Mhz Apple II+ that my Dad bought while I was still in junior high. Apple introduced me to the digital world of green monochrome screens, BASIC, and the creation of horrible continuous-paper banners created with PrintShop and a dot matrix printer. I began working with an 8Mhz/1MB RAM Mac Classic made publicly available in a student government office my freshman year of college. I plunked down my own chunk of change on a Mac Centris 610 two years later, which quickly paid for itself with freelance design work.

Wired bought a small group of PowerBook G3s for us at the end of 1997, and I fell in love with the Mac design aesthetic. A sleek black notebook with subtle curves, and one of the first working portable DVD drives. It was a beautiful machine worthy of showing off everywhere I went. Six months later, I upgraded my outdated Centris for a beige PowerMac G3 desktop, two months before the bondi-blue G3′s came out.

Downfall

My Mac idolatry began to wane the following year. My days were filled with system crashes, extension conflicts, frozen applications just before saving, and font manager nightmares. Wired MIS began to drop support for Macs, so designers were left to fix their own problems. Lycos had swallowed up Wired by that time, and everyone back in Boston was using Windows. It was too painful to share files or communicate cross-country with a company who knew nothing but 95 and NT.

In August of 1999, I stepped out into the streets and bought my first dose of the dark side. Well, sort of. The cool part of the dark side. If any designer ever owns a Windows machine, it’s at least partially understandable when the dealer is Sony and the vice is Vaio. Such was my case, but this purchase was a bad hit — this super-slim Vaio Z505 ran Windows 98. A horrible introduction to a recreational use of Windows. I could suddenly share files and what not with my Boston colleagues, but I was greeted on a daily basis with the BSoD, and could never successfully enter standby or hibernation modes. I’m sure both Sony and Microsoft share the blame for that one.

The following year, I eBayed my original Vaio in exchange for higher grade stuff. A newly redesigned dockable Vaio R505 in the same series, this time running Win2000. And this is where my addiction grew. I finally learned what Windows was all about. Why it was used. Why Microsoft had such high market share. Win2k was stable.

I never crashed when using it.

My fonts loaded correctly every time. I could reliably collaborate with teams in Boston via NetMeeting. I studied the OS inside and out, and learned how to make it mine. I could push pixels around in Photoshop and have the power of IIS under the hood on the same machine.

Slippery Slope

ASP was a welcome addition to the tired HTML and SSI tricks of this designer. I could suddenly create dynamic pages and serve them directly from my laptop. Entire design prototypes could be built using one or two templates. I learned Windows server administration, and took over the job of managing a machine for our User Experience group back in Boston through terminal services. I built a custom CMS to manage the Lycos Style Guide, and learned how to make connections with databases to power portions of the site.

I was hooked on a drug from Redmond.

My Wired G3 PowerBrick sat in a file cabinet drawer while I fell further down the rabbit hole. The G3 was a cinder block by today’s laptop standards. I didn’t want to lug around an 8-pound back-breaker. It couldn’t even handle the newfound tasks that my made life so much easier. My shiny bluish-silver Vaio was barely over 4 lbs., and it tagged along with me everywhere I went. When it came time to upgrade software, the Windows versions got the attention, while my collection of Mac-based software continued to grow sorely outdated, further taking away any remaining rationale to break my current habit.

Loss of Hope

Toward the end of 2001, I desperately wanted to replace my G3 desktop. The big box generated an unbearably loud hum, and it took up way too much real estate beneath my desk. I debated giving up Mac entirely in exchange for my new addiction. But I couldn’t bear the thought of completely abandoning my previous life. I purchased a gorgeous new PowerBook G4 at wholesale cost from a counselor at CompUSA. I suppose it was an attempt at salvaging my sense of loyalty which was gasping for air. The G4 booted OS 9 by default. But it also had this new thing called OS X that I wasn’t so sure about.

I had long fallen out of Mac circles, and knew nothing about OS X, other than what I had seen at MacWorld. The major OS rebuild seemed rather disappointing to me. All I could think was that it looked a little too sugar-coated for a professional designer. And the screen type was so big. Was Apple compensating for poor anti-aliasing? I didn’t understand all the changes in OS X, and hadn’t yet taken much time to learn my way around a Unix file system.

The darkness was closing in.

Sadly, the G4 saw very little light of day once it was purchased. It sat conveniently out of the way inside a hall closet. I pulled it out now and then to cross-check my stylesheet hacks on Wired News prototypes over the summer. Hardly the full potential of a 667 Mhz G4 processor. But what else did I need it for?

Denial

Around March of 2002, I upgraded to Windows XP Pro. The deal with the dark side was sealed. Finally a stable operating system from Microsoft that possessed plenty of eye appeal. Many of the new features of XP made so much logical sense. Grouping of taskbar buttons, hiding inactive system tray icons, built in support for wireless networking, and common tasks based on folder type. It proved to me that Microsoft had been conducting a lot of user testing and was paying attention to the resulting feedback.

The pusher got smarter.

XP was fast and slick. It made me feel good. It stole some of the UI philosophy from Apple, but didn’t go overboard with decoration. Put XP beside OS X, and purely based on the visuals, I’d pick the former any day, especially considering smaller screens. XP didn’t abuse the screen real estate that OS X carelessly occupied. I could customize the interface in XP by turning off any of the visual effects I found overly gratuitous. I missed that level of control in OS X.

Whenever I pulled the G4 out of the closet, it felt like the OS just got in my way. It didn’t allow me to accomplish a task without concentrating on the awkwardness of the OS itself. By this time, I knew Windows inside and out — how to manipulate it and make it work for me. In OS X, it seemed I was always scrolling to find something. Nothing ever fit on the screen, even though the PowerBook screen was 3 inches larger (and 128 pixels wider) than my Vaio. I had no reason to go back. I was completely comfortable with Windows.

Admission

At what point did I realize the problem? This required admitting a problem might actually exist. Was there one? After enough friends and colleagues expressed their surprise and dismay in the depth of my dependency on the Windows environment, I started to wonder.

The first step toward recovery is admitting the problem.

Could such a reliance be harmful? Had I gotten sucked too deep down the hole? It was time to step back and start evaluating. Time to consciously reconsider my dependency and take another look from the outside. I’ve always had intrigue with the new Mac OS, and a fascination that Apple chose to base its underpinnings on open source software. But I hadn’t taken the time to give up what I used to know so well about OS 9.

Last weekend, I took my first two steps and reopened my mind to other possibilities. I bit the bullet and upgraded the G4′s OS to version 10.2. I also picked up a copy of David Pogue’s Mac OS X, The Missing Manual. It’s taking me time to relearn something so entirely foreign. But I’m quickly discovering the reasons behind the changes, and the advantages and power of this new OS.

As I acknowledge the problem with one drug, I’m only attempting to replace it with another. I’m learning how Apple can help temper my dependency on Windows. But I won’t ever be able to escape Windows entirely. It’s ubiquitous. No matter when, or how much I turn back to Mac, I’ll always be a recovering Windows user.

(Translated into: Japanese)