![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Text is dependent on the user's system, not yours
One of the greatest benefits of the Web is the ability to distribute a message—in the form of a Web page—to millions of users' systems. You can craft that message, define it, style it, and present it in an effective Web page to computers all around the world. Of course, one of the greatest drawbacks of the Web is that you're suddenly dealing with those millions of users' systems. You're limited by their software, their operating system, their monitor size, even their right- or left-handedness.
In fact, that's the whole point of HTML, CSS, XHTML, ECMAScript, JavaScript, and so on. By issuing a set of standards, you can build your pages with some reasonable idea of what your friends, family, customers, and random surfers will have available to them, and therefore available to you. Building a table or styling a font to show emphasis is no longer a proprietary affair. However, while Web standards have come a long way, there's still a lot that is not standardized.
Most users have a small set of fonts
Chief among the things you can't count on when it comes to other users' systems is fonts. First, there's the almost insurmountable issue of language. Common sense suggests that a Japanese computer probably won't have that odd English handwriting font you just fell in love with. But even if you presuppose your site will only be seen by people on computers who share your primary language, there are thousands, even tens and hundreds of thousands, of font faces. And if you're design-inclined at all, you're probably already sporting some additions to the standard font set your computer came with.
The truth is, though, most users aren't designers. They're not programmers, or authors, or employed by a company that makes even its secondary or tertiary income through computers. That means you're stuck with unexciting font faces like Arial or the ever-popular Times Roman (or if the system is quite cutting-edge, maybe even Times New Roman). The sarcasm you sense here is intended, to point out what is often overlooked: If you're even reading an article on IBM developerWorks, you're not in the majority of computer users. Counting on even a reasonable percentage of your users' machines to have the same fonts as you do is a bad idea.
The apparent result of this, then, is that you're dramatically limited in what fonts you can use on your Web sites. If you select a particularly unusual font face for your Web page, expect confused calls, complaints, or dead silence as users never acknowledge they saw or understood your site at all. That's probably because they're seeing a much less attractive, and potentially unreadable, font face instead of your chosen font face. Their text might no longer fit on the screen, or it might run off the edges. That's because when the font you choose isn't available, users' systems revert to (in most cases) the simplest and often most boring and unattractive font face that their system has available.
Even those fonts are not always reliable
Further, even when you do know that users share a common set of fonts with you, there are differences. Use "Arial Rounded MT Bold" on Microsoft®Windows in an InDesign or Word document, and send that document to a Mac® user with the same font. There will be problems; the Mac complains that "Arial Rounded MT Bold (TT)" is not available. Suddenly, the entire document looks malformed and is covered with an error color or warning. Why? Because the two systems don't quite match up font-wise. The same problem is true when you move from Windows XP to Windows Vista, or Mac OS to Mac OS X. Add Linux®, Unix®, Solaris®, or other *NIX variants, and this situation gets really ugly.
In fact, the same font on the same system sometimes gets named differently. Operating systems try very hard to avoid font naming clashes, so your version of Times New Roman might not quite match mine. The result? The same: confusion, unattractive Web pages, and a message that was beautiful on your machine, but is clumsy and potentially ugly on another's machine. So how do you manage to avoid font boredom while still making your page viewable and enjoyable to a vast unknown number of font-maligned systems?
In the last couple of years, DSL and cable modems have opened up new alternatives to Web designers and developers. You still shouldn't put 1MB images on your site, but downloading a 10 or even 100k image is no longer that big of a deal. Graphic-rich sites have made "heavier" Web pages—ones that have more resources to download for the user—acceptable and even the norm. Visit http://www.apple.com or even CNN online, and there are graphics all over even the front page. Clearly, the expectation of a faster connection to the Internet is common place.
With the realization that more images and larger images were okay came another realization: Images are ubiquitous! You don't have to worry about an image being displayed correctly on another system. While there are sizing issues (does it all fit on the user's screen?) and download issues (what if the user still has a 56k modem?), the problem of fonts vanishes. So users of your site no longer have to have "Skippy Sharp" installed (the Mac version, from 2006, in a .font format, that is). Instead, you can use your font to write whatever text you need in PhotoShop, convert the bit of text into an image, and then display that image proudly on your site.
The end result is a Web full of images, even when the images are of text. Look around the Web these days, and you'll see that most logos, titles, headings, and sometimes even the content on a page, are represented by images. While it's still a bad idea to go too crazy with images, it seems like using image-based text (or graphical text) is the wave of the future. That is, until Google came along and threw a proverbial wrench in the works...
HTML and XHTML both have their roots in SGML, the Standard Generalized Markup Language. SGML was created for organizing and tagging documents. The idea of graphics was an afterthought at best. Even when graphics were an issue, SGML was ultimately about text, text, text. That's also how HTML began: essentially as a way to represent text on a Web-accessible page. All the stylistic eye candy was extra.
When graphics started including text in them,
though, that all changed. Many pages popping up on the Web were nothing but a
collection of images, with an occasional alt or title attribute thrown in on an img tag
for good measure. Even with HTML and XHTML strict requiring alt
attributes on images, text had become an unwanted nuisance. Images made it much easier for a
designer to create a beautiful page, without fear of that beauty being fouled up by another
user's limited system. The image would appear identically on any system (barring resolution
or color problems, which are a subject for an entirely different article altogether). But
with the increase in images, text began to have less and less meaning.
At first blush, it might not seem a huge problem that text is less important on modern Web pages. If the point of the Web is to communicate a message, and images work better for that communication—or at least for providing clarity in communication—then is there really a problem with a page full of images? Or even a page made up entirely of images?
The answer is a resounding,
"Yes," highlighted by Google more than any other organization. Google spiders the Web, like
most search engines, looking for... text! That's right; Google has no way to
interpret an image with text embedded in the image. Google's spiders ignore an array of
images with carefully written descriptions of your products. Their search engine will
completely disregard how beautiful your site is, instead focusing on what's in your HTML.
And if all that's in that HTML is a bunch of img tags, you'll be
hard-pressed to see your site's URL anywhere in the top 100 of Google's search results, even
if the keyword entered by a searching user seems to exactly match your
site.
This aspect of Google (and, really, all major search engines) is crippling if you're really trying to get out a message. Most people's home page is Google or Yahoo!'s search engine. Most Web sessions begin with a search. What that means is that unless someone already has your specific URL, they're not going to find you without some help. And, no matter how great your site looks, search engines simply can't figure out what your text says (let alone what it means).
Don't forget about accessibility
On top of that, the Web has become a place for those who need information, regardless of those people's limitations. Ten years ago, the idea that the vision-impaired or even the blind might use the Web seemed ridiculous; today it is a simple reality. In fact, if you have any desire to see your site recognized, used by, linked to, or even acknowledged by most civil and governmental agencies, you've got to have an accessible site. It's a mandate, not an option.
So what does accessibility
have to do with images? In fact, what does accessibility even mean? In the realm of Web
pages and simplicity, it means that a screen reader or similar device can make sense of your
page, and relay its contents, usually audibly, to someone who's disabled. And, no surprise,
a screen reader can make no more sense of your image than can Google's search engines. Once
again, you're left with the oft-ignored alt tag to represent in a
few words what your hours of image manipulation produced. Unsurprisingly, the alt tag almost always comes up lacking.
Your most important text is your titling...
What's the
most important text on your page? Ask anyone, and you may hear about a particular
description of a top-selling product, or a slogan, or a celebrity testimonial. But all of
those answers presuppose someone knows what the heck you're selling, or talking about, or
endorsing. That information comes from the title of your page. That's often the text within
your page's title tag in the document head, but it's also
something that's predominantly displayed on every page of a good site. Open up five or six
Web sites; you'll usually find the title along the top and then iconized in the top-left
corner.
...and your most important text is usually graphical
Of course, with something as important as a title, you want it to look amazing... right? So fire open PhotoShop, select a cool and unique font, and... confound the screen readers and search engines. Sure, you've got your title in your document's head, but repetition is a good thing, and indicates importance, to you, to screen readers, to your audience, and to search engines. So even when Web designers use large amounts of regular, non-image text, they often still put the title of a Web page in an image.
So what's the solution? It's not, happily, to go back to an all-text, all-the-time approach to Web design. It's not to ditch all those beautiful images you've created, or to stick with Arial for the title of every page you write. The solution is to amalgamate the textual history and abilities of HTML and XHTML with CSS, and get the best of both worlds.
Structure, content, and presentation
To make
that a little more concrete, you need to think about your Web pages as having several
components: structure, content, and presentation. The structure of your page is the
HTML and XHTML tagging. body, div,
li, and p are all examples of
structural elements. They define the organization of your page and delineate different
sections of content.
Content is the text of your page. While you can define content more broadly, for the sake of this discussion, content is just the text within your page's structure. Of course, when you think about content that way, it's obvious that image-based text effectively removes content from the page. Content is replaced with imagery. That's a very limited perspective—the idea that content is purely text—but it's a good meme to use when you consider that Google, screen readers, and software can't interpret your images. So for Google, your content is text.
The last component, presentation, is what makes us all "Oooh" and "Aaah." Images, color, font faces, sizing, even all the little rollover effects and drag-and-drop wonders of the modern Web page fall into this category (although some require another component, behavior, to drive the action). Image-based text is certainly presentation, not content. The problem is that presentation is flat-out ignored by anything software-driven or mechanical, like all those search engines and helpers for the disabled.
The big realization, and the first step to Web page nirvana, is that these three layers are not orthogonal. In other words, you can't choose to provide content or presentation for a line of text. You layer each layer. (Yes, that sounds silly, but despite how obvious this statement is, it's missed by most.) Your content sits "on top of" your structure. And your presentation sits "on top of" your content. The styles you apply in your CSS affect your content, but it's usually a layer "above" that content. The presentation doesn't override the content, it just augments it.
But if presentation and content, in particular, are layers, why not do more than just augment content with presentation? Instead, suppose that you wanted to completely cover a piece of content with a presentation. Suppose you wanted to take a piece of content—say, a nice textual title for your page—and layer on top of that text a beautiful, high-resolution image-based version of that title. Then, you're getting the benefits of both content and presentation. Search engines like Google recognize, categorize, and index your textual content, and screen readers can deal with the accurate textual content. But humans, who love eye candy and fancy script, still get to see the "top"-most layer, the presentation.
Effective Web pages use all the available layers
Once you realize that the three components of a Web page are layers, you can put them to use. Let's build a very simple "splash" or introduction page to a Web site and demonstrate how a graphically rich page can still have a textual underpinning.
Begin by laying out your page with structure. HTML head and body tags segregate your document into
sections. Then, identify the basic components you want on the page. For this splash page,
there are three:
- A title, "Tom Doerr Guitars."
- A logo or slogan, "fine handcrafted guitars... instruments without compromise."
- Some large image that depicts the essence of the site; probably a guitar of some sort.
Notice that all the presentation-specific details are omitted. At this stage, we're talking about pure content and structure.
Once that's decided, go ahead and create your XHTML. Don't worry about CSS; just build the basic page. Listing 1 shows a simple beginning.
Listing 1. This simple XHTML is all content and structure
<![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Tom Doerr Guitars</title>
</head>
<body>
<div id="splash">
<div id="title">Tom Doerr Guitars</div>
<div id="slogan">
fine handcrafted guitars... instruments without compromise
<div>
</div>
</body>
</html>]]> |
This is pretty "basic" XHTML. There's a heading, the title, and the body of the
page. Within the body, there's a div named "splash"; that's
pretty standard Web practice. divs organize and break up a page,
and this is no exception. This main div organizes all the
content.
Then, there's the title of the page. We know we'll want to work with this
title, so we use another div to identify the title, this time
with an id of "title." So at this stage, we are doing a little bit of presentation thinking.
We're using structure (divs) to identify places where we later
will layer graphical text on top of the existing text. Still, details about that layering
are largely ignored.
The same is done for the slogan: another div is created. Within that div is the textual slogan.
Again, no presentation other than the identifying divs.
Perhaps surprisingly, that's it! Figure 1 shows this page, which is a pretty dry, boring piece of Web design. Thankfully, there's lots more to come.
Figure 1. Web pages with no presentation are pretty lackluster
The key here is that Google or any other search engine will find text that it can index. The title of the site is clear, as is the slogan, even if to the human eye they look pretty awful.
At this stage, you're ready to think a bit about presentation. We know we have three elements, and now you should consider which are textual, and which are graphical:
- A title, "Tom Doerr Guitars." Let's use an image for this with a custom or unique font.
- A logo or slogan, "fine handcrafted guitars... instruments without compromise." This should be a custom font, too.
- Some large image that depicts the essence of the site; probably a guitar of some sort. This is obviously an image.
So in this case, there's actually nothing on the page that's viewable and isn't an image!
Once you know what's an image, and what's not, you need to identify
structurally the parts of your page that will be hidden, in particular, text. Looking at
Listing 1, that means that both the title and the slogan will be hidden. To make it easy to
find these later, surround both bits of text within spans. Listing 2 shows what the XHTML should look like now.
Listing 2. Surround hidden text in span tags
<![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Tom Doerr Guitars</title>
</head>
<body>
<div id="splash">
<div id="title">]]><b><![CDATA[<span>]]></b>
<![CDATA[Tom Doerr Guitars]]><b><![CDATA[</span>]]></b><![CDATA[</div>
<div id="slogan">
]]><b><![CDATA[<span>]]></b><![CDATA[fine handcrafted guitars...
instruments without compromise]]><b><![CDATA[</span>]]></b><![CDATA[
<div>
</div>
</body>
</html>]]> |
Using spans here is probably a bit excessive; all the
text within the title div will be hidden, as will all the text in
the slogan div. Still, it's a good practice to further identify
text using spans. If you later wanted part of the text in the
slogan div to be graphical, and another part—say a sub-title
or elaboration—to remain normal text, you could surround just the hidden text within a
span.
Either way, you now have an XHTML page with clearly identifiable sections, as well as hidden text that's marked up and easy to locate.
Cover your text with graphical text
With content and structure in hand, you're ready to add the presentation layer. Most of this is the same old presentation you've always been doing: a CSS stylesheet with lots of selectors, rules, and formatting.
First up, add a background color, perhaps a background image, set default font color, style, and alignment, and do anything else you'd normally do with CSS. Listing 3 shows a simple stylesheet for the Tom Doerr Guitars Web site.
Listing 3. CSS for Tom Doerr Guitars site
@charset "UTF-8";
/* Main CSS Stylesheet for Tom Doerr Guitars */
body {
background-color: #5D1008;
font-family: Verdana, Helvetica, Arial, sans-serif;
margin-top: 150px;
margin-left: 75px;
}
#splash {
height: 343px;
width: 514px;
background: url(../images/splash_guitar.gif) no-repeat bottom left;
}
#title {
position: absolute;
top: 80px;
left: 275px;
height: 93px;
width: 475px;
}
#slogan {
position: absolute;
top: 260px;
left: 375px;
height: 94px;
width: 399px;
}
|
You also need a reference to this CSS in your XHTML. That's shown in Listing 4.
Listing 4. Reference your presentation CSS in your XHTML
<![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Tom Doerr Guitars</title>
]]><b><![CDATA[<link type="text/css" rel="stylesheet"
href="styles/doerr.css" />]]></b><![CDATA[
</head>
<body>
<div id="splash">
<div id="title"><span>Tom Doerr Guitars</span></div>
<div id="slogan">
<span>fine handcrafted guitars... instruments without compromise</span>
<div>
</div>
</body>
</html>]]> |
Load this up in your browser, and you should see something like Figure 2. The page is coming along nicely: It's got some style, and even the text is in the general location that the final images will go. Obviously, getting your presentation right is trial-and-error, but there's nothing unique about how this was handled. You're styling the document normally, without worrying about hiding the text (yet).
Figure 2. Presentation adds a lot to a page
Hide the text that should be hidden
Now
you need to hide those two blocks of text. Thanks to the span
tags and easily locatable divs, this is pretty simple. First, you
need a rule that selects each bit of text in your CSS. Then, you just need to set the display property to the value "none." Listing
5 shows updated CSS to reflect these two
changes.
Listing 5. Hide the text you don't want to be seen
@charset "UTF-8";
/* Main CSS Stylesheet for Tom Doerr Guitars */
body {
background-color: #5D1008;
font-family: Verdana, Helvetica, Arial, sans-serif;
margin-top: 150px;
margin-left: 75px;
}
#splash {
height: 343px;
width: 514px;
background: url(../images/splash_guitar.gif) no-repeat bottom left;
}
#title {
position: absolute;
top: 80px;
left: 275px;
height: 93px;
width: 475px;
}
#title span { display: none; }
#slogan {
position: absolute;
top: 260px;
left: 375px;
height: 94px;
width: 399px;
}
#slogan span { display: none; } |
This
hides the text, and you're still not using anything particularly tricky. In the case of the
title text, for example, the selector is just #title span. #title selects a div with an id of "span."
Then, span at the end selects span
tags within that div.
Load up your page, and you'll see something like Figure 3. Now the text is gone, and all that's left is to add the textual imagery.
Figure 3. Now the text is hidden from view
Of course, this presentation doesn't affect the actual content of the page. Despite not being seen, the title and slogan text is still in the underlying XHTML. That means that search engines, spiders, and screen readers all still have what they need to process and work with the page. Now, though, humans are faced with a higher-level presentation that "obscures" or hides this content.
Show the images you want to display
For all practical purposes, you've now got two empty
divs. Of course, if you've got imagery you want to display, and
you've got a div in the right place, it's trivial to display
images. Just use the background: url property in CSS. Listing 6 shows one final addition to the CSS that adds a background
image to both of the divs where graphical text should
go.
Listing 6. Use background images to display graphical text
@charset "UTF-8";
/* Main CSS Stylesheet for Tom Doerr Guitars */
body {
background-color: #5D1008;
font-family: Verdana, Helvetica, Arial, sans-serif;
margin-top: 150px;
margin-left: 75px;
}
#splash {
height: 343px;
width: 514px;
background: url(../images/splash_guitar.gif) no-repeat bottom left;
}
#title {
position: absolute;
top: 80px;
left: 275px;
height: 93px;
width: 475px;
background: url(../images/title.gif) no-repeat top left;
}
#title span {
display: none;
}
#slogan {
position: absolute;
top: 260px;
left: 375px;
height: 94px;
width: 399px;
background: url(../images/slogan.gif) no-repeat top left;
}
#slogan span {
display: none;
} |
Load up the page again, and you'll see a rather striking difference; Figure 4 shows the results.
Figure 4. Graphical text now appears
One last word
of caution: You should favor using a background image in a div
over actually placing an img tag in your XHTML. First, your XHTML
correctly maps to the displayed page. There's a section (represented by a div) with text in it (the title, and then the slogan). Second there
is a single item in each section: text. That text is actual text in the XHTML, and rendered
(graphical) text in the browser. Finally, if you add an img into
your XHTML, you've got to further position the image, as well as the div. In short, it's simpler and more accurate to use divs
with actual text, and then drop in a background image for the div.
Writing to the semantic Web is a much harder task than it seems. You've got to create content and organize that content with XHTML structure. Not only does the content have to be accurate, it needs to be complete. In other words, the content needs to fully represent a page. So an image needs some content-based representation. Without complete content, Google and other search engines are left to ignore your pages, or at best only partially index them.
But you're still tasked with creating compelling presentation. Pure text won't cut it, even on the most information-driven sites. You've got to employ CSS to get your pages looking crisp and usable, all while working within that content and structure you've already defined. A great-looking page isn't useful without accurate and complete content. But accurate and complete content is rarely acceptable without an appropriate presentation.
So build structure, content, and presentation. Layer one on top of the other, and allow certain layers to be visible to certain types of devices. Your content can be visible to search engines and screen readers without jarring the human eye. When you complete a page, you should have a nice-looking and textually accurate Web page.
| Description | Name | Size | Download method |
|---|---|---|---|
| Zip file containing the sample application | doerr.zip | 259KB | HTTP |
Information about download methods
Learn
- Read some formal theory on Fahrner Image Replacement, the
technique detailed in this article.
- mezzoblue takes on image replacement, with some very
specific constraints, and tries to improve on Fahrner Image Replacement.
- You can also focus on accessibility when dealing with content and presentation, looking in depth
at screen readers in particular.
Get products and technologies
- Download the images,
XHTML, and CSS used for the Tom Doerr Guitars splash page.
- Head
First HTML with CSS & XHTML (Beth Freeman and Eric Freeman, O'Reilly Media, Inc.):
You'll get terrific introduction and concept-rich instruction in XHTML and CSS by reading
this book.
Discuss
- developerWorks blogs: Get involved in the developerWorks community.
Brett McLaughlin is a best-selling and award-winning non-fiction author. His books on computer programming, home theater, and analysis and design have sold in excess of 100,000 copies. He has been writing, editing, and producing technical books for nearly a decade, and is as comfortable in front of a word processor as he is behind a guitar, chasing his two sons around the house, or laughing at reruns of Arrested Development with his wife. His last book, Head First Object Oriented Analysis and Design, won the 2007 Jolt Technical Book award. His classic Java and XML remains one of the definitive works on using XML technologies in the Java language.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
