Learning Web Design Third Edition- P5 pdf

Part I: Getting Started
26
Putting It All Together
When I first began writing HTML, it helped me to think of the tags and text
as “beads on a string” that the browser deals with one by one, in sequence.
For example, when the browser encounters an open bracket (<) it assumes
all of the following characters are part of the markup until it finds the clos-
ing bracket (>). Similarly, it assumes all of the content following an opening
<h1> tag is a heading until it encounters the closing </h1> tag. This is the
manner in which the browser parses the HTML document. Understanding
the browser’s method can be helpful when troubleshooting a misbehaving
HTML document.
But where are the pictures?
Obviously, there are no pictures in the HTML file itself, so how do they get
there when you view the final page?
You can see in Figure 2-3 that each image is a separate graphic file. The
graphics are placed in the flow of the text with the HTML image element
(img) that tells the browser where to find the graphic (its URL). When the
browser sees the img element, it makes another request to the server for the
image file, and then places it in the content flow. The browser software brings
the separate pieces together into the final page.
The assembly of the page generally happens in an instant, so it appears as
though the whole page loads all at once. Over slow connections or on slower
computers, or if the page includes huge graphics, the assembly process may
be more apparent as images lag behind the text. The page may even need to
be redrawn as new images arrive (although you can construct your pages in
a way to prevent that from happening).
Putting It All Together
To wrap up our introduction to how the Web works, let’s trace the stream of
events that occur with every web page that appears on your screen (Figure 2-4).
You request a web page by either typing its URL (for example, http://jen-

skitchensite.com) directly in the browser, or by clicking on a link on the
page. The URL contains all the information needed to target a specific
document on a specific web server on the Internet.
Your browser sends an HTTP Request to the server named in the URL
and asks for the specific file. If the URL specifies a directory (not a file), it
is the same as requesting the default file in that directory.
The server looks for the requested file and issues an HTTP response.
If the page cannot be found, the server returns an error message. The
message typically says “404 Not Found,” although more hospitable
error messages may be provided.
1
2
3
a.
Putting It All Together
Chapter 2, How the Web Works
27
4
The browser parses the
document. If it has images, the browser
contacts the server again for each
graphic file.
5
The page is assembled in
the browser window.
H
T
T
P
r

e
q
u
e
s
t
H
T
T
P
r
e
s
p
o
n
s
e
2
The browser sends
an HTTP request.
Server
Oops, no file
If the file is not on the server,
it returns an error message.
Server Contents
index.html
Browser
1
Type in a URL or click on a link in the browser.

3
The server looks for the file and
responds with an HTTP response.
“I see that you requested a directory,
so I’m sending you the default file,
index.html. Here you go.”
masthead.gif
spoon.gif
index.html
masthead.gif
spoon.gif
Figure 2-4. How browsers display web pages.
If the document is found, the server retrieves the requested file and
returns it to the browser.
The browser parses the HTML document. If the page contains images,
(indicated by the HTML img element), the browser contacts the server
again to request each image file specified in the markup.
The browser inserts each image in the document flow where indicated by
the img element. And voila! The assembled web page is displayed for your
viewing pleasure.
b.
4
5
Part I: Getting Started
28
Test Yourself
Test Yourself
Let’s play a round of “Identify that Acronym!” The following are a few basic
web terms mentioned in this chapter. Answers are in Appendix A.
HTML a) Home of Mosaic, the first graphical browser

W3C b) The location of a web document or resource
CERN c) The markup language used for all web documents
HTTP d) Matches domain names with numeric IP addresses
IP e) A limited set of letters, numbers and symbols
URL f) Internet Protocol
NCSA g) Particle physics lab where the Web was born
DNS h) Protocol for transferring web documents on the Internet
ASCII i) The organization that monitors web technologies
Answers: ____________________________________________________________
1.
2.
3.
4.
5.
6.
7.
8.
9.
29
IN THIS CHAPTER
How variables on the
user’s end affect the
way your page looks and
performs, including:
Browser version
Alternative browsing
devices
User preferences
Platform
Connection speed

Browser window size
and monitor resolution
Monitor color
As a web designer, you spend a lot of time creating pages and tweaking them
until they look good in your browser. Before you grow too attached to the
way your page looks on your screen, you should know that it is likely to look
different to other people. That’s just the nature of web design—you can’t
guarantee that everyone will see your page the way you do. The way your site
looks and performs is at the mercy of a number of variables such as browser
version, platform, monitor size, and the preferences or special needs of each
individual user. Your page may also be viewed on a mobile device like a cell
phone, or using an assistive device like a screen magnifier or a screen reader.
This unpredictable nature of the Web is particularly challenging if you have
experience designing for print, where what you design stays put. As a print
designer who made the transition to web design, I found I needed to let go
of controlling things such as page size, typography, and precise color. Having
a solid understanding of the web environment allows you to anticipate and
plan for these shifting variables. Eventually, you’ll develop a feel for it.
This chapter looks at the ways in which browsers, user configurations, plat-
form, connection speed, computer monitors, and alternative browsing envi-
ronments affect the design and functionality of web pages. It suggests some
tips for coping along the way.
Browser Versions
One of the biggest challenges in designing for the Web is dealing with
the multitude of browsers in current use. Although the current version of
Microsoft Internet Explorer running on Windows makes up the lion’s share
(60 to 80% as of this writing), there are at least a dozen browser versions that
web developers pay attention to, and hundreds more obscure or antiquated
browsers still in use. See the sidebar, Browser Roll Call, for more information
on relevant browsers.

In the no-so-distant past, browsers were so incompatible that web authors
were forced to create two separate sites, one for Internet Explorer and one
for Netscape (the only two players at the time). Fortunately, things have
THE NATURE OF
WEB DESIGN
CHAPTER
3
The nature of web
design is that there is no
guarantee that everyone
will see your page the way
you do.
Part I: Getting Started
30
Browser Versions
Browser Roll Call
It is important that web developers be familiar with the browsers in current use.
Although there are hundreds of browsers out there, only about a dozen make up 99%
of browser usage. The A-list browsers in Table 3-1 offer solid standards support and
represent the vast majority of web traffic.
Older and niche browsers listed in Table 3-2 may be tested to be sure that the content
is available and accessible, but there is no effort made to reproduce the A-list browsing
experience on these browsers.
It should be noted that the browsers listed here, and the Usage Statistics in particular,
reflect the browser landscape as of the writing of this book. Things are sure to be different
by the time you are reading this. For updated browser statistics, go to www.thecounter.
com or www.w3schools.com/browsers. Of course, the most meaningful statistics are those
taken from your own site. 3% of visitors to your blog and 3% on a site like Yahoo! are
different sized crowds indeed, and may warrant different support decisions.
Table 3-1. A-list browsers (generally tested for a consistent presentation and scripting experience)

Browser version Platforms Released Stats* Notes
Internet Explorer 7 Windows XP, Linux,
Unix
2006
14%
IE7 improves support for CSS2 and fixes many of
the bugs in IE6. It’s share will eventually surpass IE6
Internet Explorer 6 Windows, Linux,
Unix
2001 58% IE6 usage will decrease as IE7 is distributed.
Internet Explorer 5.5
and 5
Windows, Linux,
Unix
2001 (5.5)
1999 (5)
1% There are significant differences in the way IE5
and 5.5 supports CSS, requiring workarounds
until these versions finally go away. Some develop-
ers have already stopped supporting IE5 with the
release of IE7.
Mozilla Firefox 1.0 Windows, Linux,
Unix, Macintosh
2005 12% Fast and standards-compliant, this is the recom-
mended browser of the development community.
Netscape 7 & 8 Windows, Linux,
Unix, Macintosh
2002 1% Netscape once dominated; now it is barely a blip
on the radar.
Opera 8+ Windows, Linux,

Unix, Macintosh
2005 1% Opera is popular in the development community
for its small size and standards compliance.
Safari 1.0 and 2.0 Macintosh OS X 2002 (1.0)
2005 (2.0)
3% Safari comes with OS X. Safari 2.0 offers the most
advanced CSS support of any current browser.
Safari 3.0 Macintosh OS X,
WIndows 2007
2007 n/a In public beta as of this writing.
Table 3-2. Older browser versions (tested only to make sure content is available and accessible)
Netscape 4 Windows, Linux,
Unix, Macintosh
1999 < .5% Netscape 4 has only partial support for CSS and
other standards. It is represtentative of legacy
browsers.
IE 5 (Mac) Macintosh 2000 < 1% The best standards-compliant browser option for
users who must still use Mac OS 9
Lynx (or other text only
browser)
old versions for
Windows, Mac, Unix
1992 n/a A text only browser is useful for testing the accessi-
bility of content on less-than-optimal browsers.
* Usage statistics taken from TheCounter.com in April 2007.
N o t e
For a complete list of all browers, old
and new, see browsers.evolt.org.
For Further Reading
The article “Graded Browser Support”

by Nate Koechley at Yahoo!’s
Developer Network aptly sums up the
contemporary approach to browser
support. Read it at developer.yahoo.
com/yui/.articles/gbs/gbs.html
Browser Versions
Chapter 3, The Nature of Web Design
31
improved dramatically now that browsers have better support for web stan-
dards established by the World Wide Web Consortium (W3C for short). The
situation will continue to improve as older, problematic browser versions
such as Internet Explorer 5 and Netscape 4 fade out of existence.
Fortunately, nearly all browsers in use today support HTML 4.01 and
XHTML standards, with only a few exceptions. That doesn’t mean that an
(X)HTML document will look identical on all browsers—there may still be
slight differences in the default rendering of text and form elements. That’s
because browsers have their own internal style sheets that determine how
each element looks by default.
Instead, the new challenge for cross-browser consistency comes in the varying
support of certain aspects of Cascading Style Sheets (CSS). Although most
of the basic style sheet properties can be used reliably, there are still some
bugs and inconsistencies that may cause unexpected results. Figure 3-1 shows
how the same web page may be rendered differently based on the browser’s
support of CSS.
Coping with various browser versions
How do professional web designers and developers cope with the multitude
of browsers and their varying capabilities? Here are a few guidelines.
Don’t sweat the small stuff. As a web designer, you must allow a certain
amount of variation. It’s the nature of the medium. What is important
isn’t that form input boxes are all precisely 15 pixels tall, but that they

work. The first lesson you’ll learn is that you have to let go.
Stick with the standards. Following web standards—(X)HTML for docu-
ment structure and CSS for presentation—as documented by the W3C
is your primary tool for ensuring your site is as consistent as possible on
all standards-compliant browsers (that’s approximately 99% of browsers
in current use).
Internet Explorer 5 (Windows 2000)
Because of IE5Win’s implementation of CSS, centering
is broken, columns overlap, and the tabs run together.
Firefox 1.5
This page appears as the author intended.
Figure 3-1. The same web page may
look different on different browsers. In
this case, the problem is in inconsistent
implementation of certain style
properties by IE5 (Win). Fortunately, the
percentage of web traffic using IE5 (Win)
is down around 2% and shrinking with the
release of IE7 in 2006.
Internet Explorer 5 (Windows 2000)
Because of IE5Win’s implementation of CSS, centering
is broken, columns overlap, and the tabs run together.
Firefox 1.5
This page appears as the author intended.
Figure 3-1. The same web page may
look different on different browsers. In
this case, the problem is in inconsistent
implementation of certain style
properties by IE5 (Win). Fortunately, the
percentage of web traffic using IE5 (Win)

is down around 2% and shrinking with the
release of IE7 in 2006.
Part I: Getting Started
32
Alternative Browsing Environments
Start with good markup. When an (X)HTML document is written in logi-
cal order and its elements are marked up in a meaningful way, it will be
usable on the widest range of browsing environments, including the old-
est browsers, future browsers, and mobile and assistive devices. It may
not look exactly the same, but the important thing is that your content
is available.
Don’t use browser-specific (X)HTML elements. There are markup elements
and attributes out there that work only with one browser or another, a
remnant from the browser wars of old. Don’t use them! (You won’t learn
them here.)
Become familiar with the aspects of CSS that are likely to cause problems.
Using style sheets effectively takes some practice, but experienced devel-
opers know which properties are “safe,” and which require some extra
tweaks to get consistent results on all current browsers.
Alternative Browsing Environments
The previous section focused on issues relevant to graphical browsers used
on desktop or laptop computers. It is critical to keep in mind, however, that
people access content on the Web in many different ways. Web designers
must build pages in a manner that creates as few barriers as possible to get-
ting to information, regardless of the user’s ability and the device used to
access the Web. In other words, you must design for accessibility.
Accessibility is a major topic of discussion in the web design world, and a
priority for all web designers. While intended for users with disabilities such
as poor vision or limited mobility, the techniques and strategies developed for
accessibility also benefit other users with less-than-optimum browsing expe-

riences, such as handheld devices, or traditional browsers over slow modem
connections or with the images and JavaScript turned off. Accessible sites are
also more effectively indexed by search engines such as Google. The extra
effort in making your site accessible is well worth the effort.
Users with disabilities
There are four broad categories of disabilities that affect how people interact
with their computers and the information on them:
Vision impairment. People with low or no vision may use an assistive
device such as a screen reader, Braille display, or a screen magnifier to
get content from the screen. They may also simply use the browser’s text
zoom function to make the text large enough to read.
Mobility impairment. Users with limited or no use of their hands may
use special devices such as modified mice and keyboards, foot pedals, or
joysticks to navigate the Web and enter information.
•
•
Browsercam
A good shortcut for checking how
your page looks in a variety of
browsers (without installing them
all yourself ) is to use a subscription
service like Browsercam.com. For a
monthly fee, just enter the URL of
your page, and Browsercam captures
the screen image in every browser
configuration you can imagine.
Check it out at www.browsercam.
com. It is not a substitute for testing
performance (you can’t tell if the
scripts are working), but it can catch

style sheet and even markup issues.
D e V e l O P m e n t t I P
Accessibility vs.
Availability
Web accessibility guru, Derek
Featherstone, draws an interesting
and useful distinction between
“accessibility” for users with
disabilities and “availability” for
users with alternative devices such
as mobile phones. Read his blog
entry at www.boxofchocolates.
ca/archives/2005/08/25/accessibility-
and-availability
F O R F U R t H e R R e A D I n G
Alternative Browsing Environments
Chapter 3, The Nature of Web Design
33
Auditory impairment. Users with limited or no hearing will miss out
on audio aspects of multimedia, so it is necessary to provide alternatives,
such as transcripts for audio tracks or captions for video.
Cognitive impairment. Users with memory, reading comprehension,
problem solving, and attention limitations benefit when sites are design
ed simply and clearly. These qualities are helpful to anyone using your
site.
The lesson here is that you shouldn’t make assumptions about how your
users are accessing your information. They may be hearing it read aloud.
They may be pushing a button to jump from link to link on the page. The
goal is to make sure your content is accessible, and the site is as easy to use
as possible.

The mobile Web
The increased popularity of the Web, combined with the growing reliance on
handheld devices such as cell phones, PDAs, and palm-top computers, has
resulted in web browsers squeezing into the coziest of spaces.
Although most content accessible on mobile devices has been developed
specifically for that type of browser, an increasing number of devices now
include microbrowsers capable of displaying the same web content that you’d
see on your PC. Microbrowsers are designed to accommodate limited display
area, lower memory capacity, and low bandwidth abilities. Some have only
basic HTML support and others support the current web standards.
One limitation of handheld devices is screen size. Mobile displays are roughly
only 240 pixels square, although some have dimensions as small as 128 pixels
or as large as 320. That’s not much room to look at a typical web site. Mobile
browsers deal with the limited screen size the best they can. Some shrink the
page to fit by displaying the text content as it appears in the HTML source
document, and resizing the images to fit the screen. Others simply allow hori-
zontal scrolling. Figure 3-2 shows the Jen’s Kitchen page as it might appear in
a microbrowser on a cell phone.
Dealing with diversity
The best way to accommodate the needs of all your visitors is to design with
accessibility in mind. Accessible design not only helps your disabled visitors,
but also those using the Web on the go or under any less-than-ideal condi-
tions. You’ll also improve the quality of your content as perceived by search
engine indexing programs.
The W3C started the Web Accessibility Initiative to address the need to make
the Web usable for everyone. They developed the Web Content Accessibility
Guidelines (WCAG) to help developers create accessible sites. You can
•
•
Figure 3-2. This is the Jen’s Kitchen

web page from Chapter 2 as it might
appear on a mobile device. (The image
was taken using the Openwave Mobile
Browser Simulator available at
developer.
openwave.com.)
Figure 3-2. This is the Jen’s Kitchen
web page from Chapter 2 as it might
appear on a mobile device. (The image
was taken using the Openwave Mobile
Browser Simulator available at developer.
openwave.com.)
N o t e
Adobe Creative Suite 3 features many
tools for designing and optimizing appli-
cations for mobile devices. Learn more at
adobe.com.
N o t e
Adobe Creative Suite 3 features many
tools for designing and optimizing appli-
cations for mobile devices. Learn more at
adobe.com.
Part I: Getting Started
34
Alternative Browsing Environments
read them all at www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. The
United States government used the Priority 1 points of the WCAG as the
basis for its Section 508 accessibility guidelines (see the sidebar, Government
Accessibility Guidelines: Section 508).
While accessibility and the techniques for achieving it are vast topics, I’ve

summarized some of the guiding principles and provided pointers to useful
resources here.
Start with clean HTML. When your source document has been marked up
with appropriate, meaningful HTML elements and the content appears
in a logical order, your content will make sense in the widest variety of
circumstances, whether it is read aloud or displayed on a tiny handheld
screen.
Provide alternatives. Always provide alternatives to non-text content such as
alternative text or long descriptions for images, transcripts for audio, and
captions for video content, to better serve users with various disabilities.
Allow text to resize. If you use style sheets to specify font size, do so in rela-
tive measurements such as percentages or ems (a unit of measurement for
text equal to a capital “M” ) so that users can resize it with the browser’s
“text zoom” feature (when available).
Don’t put text in graphics. Although it may be tempting to control the
typography of a headline by putting it in a graphic, doing so makes it less
accessible by removing that content from the document. It also prevents
users from resizing the text.
Use accessibility features when creating HTML tables and forms. There are
a number of attributes in HTML 4.01 and XHTML that improve acces-
sibility by explicitly labeling columns or form fields. They’re only useful
if you take the time to use them correctly. We’ll address these features in
the tables and forms chapters, respectively.
Be careful with colors and backgrounds. Be sure that there is plenty of con-
trast between the foreground and background colors you specify. When
using background images, be sure to also specify a similarly colored back-
ground color so text is legible, should the image not load properly.
For further reading
The following resources are good starting points for further exploration on
web accessibility.

The Web Accessibility Initiative (WAI), www.w3.org/WAI
WebAIM: Web Accessibility in Mind, www.webaim.org
Dive Into Accessibility: 30 days to a more accessible web site, diveintoac-
cessibility.org
•
•
•
User Preferences
Chapter 3, The Nature of Web Design
35
Building Accessible Websites, by Joe Clark (New Riders) provides a com-
prehensive overview. Joe Clark’s web site (joeclark.org/access) features Joe’s
latest thinking and discussions on accessibility issues.
User Preferences
At the heart of the original web concept lies the belief that the end user
should have ultimate control over the presentation of information. For that
reason, browsers are built with features that enable users to set the default
appearance of the pages they view. Users’ settings will override yours, and
there’s not much you can do about it. This ensures that users who need to
alter the presentation to meet special needs, such as enlarging type to com-
pensate for imparied vision (or even just to read while leaning back in their
chairs), are able to do so.
•
If you create a site for a Federal agency, you are required by
law to comply with the Section 508 Guidelines that ensure that
electronic information and technology is available to people
with disabilities. State and other publicly funded sites may also
be required to comply.
The following guidelines, excerpted from the Section 508
Standards at www.section508.gov, provide a good checklist for

basic accessibility for all web sites.
A text equivalent for every non-text element shall be
provided (e.g., via “alt”, “longdesc”, or in element content).
Equivalent alternatives for any multimedia presentation shall
be synchronized with the presentation.
Web pages shall be designed so that all information
conveyed with color is also available without color, for
example from context or markup.
Documents shall be organized so they are readable without
requiring an associated style sheet.
Redundant text links shall be provided for each active region
of a server-side image map.
Client-side image maps shall be provided instead of server-
side image maps except where the regions cannot be
defined with an available geometric shape.
Row and column headers shall be identified for data tables.
Markup shall be used to associate data cells and header cells
for data tables that have two or more logical levels of row or
column headers.
1.
2.
3.
4.
5.
6.
7.
8.
Frames shall be titled with text that facilitates frame
identification and navigation.
Pages shall be designed to avoid causing the screen to

flicker with a frequency greater than 2 Hz and lower than
55 Hz.
A text-only page, with equivalent information or
functionality, shall be provided to make a web site comply
with the provisions of this part, when compliance cannot be
accomplished in any other way. The content of the text-only
page shall be updated whenever the primary page changes.
When pages utilize scripting languages to display content,
or to create interface elements, the information provided by
the script shall be identified with functional text that can be
read by assistive technology.
When a web page requires that an applet, plug-in or other
application be present on the client system to interpret
page content, the page must provide a link to a plug-in or
applet that complies with §1194.21(a) through (l).
When electronic forms are designed to be completed
online, the form shall allow people using assistive
technology to access the information, field elements, and
functionality required for completion and submission of the
form, including all directions and cues.
A method shall be provided that permits users to skip
repetitive navigation links.
When a timed response is required, the user shall be alerted
and given sufficient time to indicate more time is required.
9.
10.
11.
12.
13.
14.

15.
16.
Government Accessibility Requirements: Section 508