Web Design in a Nutshell | O'Reilly Media

Content preview·Buy reprint rights for this chapter

Most web authors agree that the biggest challenge (and headache!) in web design is dealing with the variety of browsers and platforms, each with its own support and implementation of HTML and scripting elements. Features and capabilities improve with each new major browser release, but that doesn't mean the older versions just go away. The general public tends not to keep up with the latest and greatest—many are content with what they are given, and many others may be using the computers of a company or institution that chooses a browser for them.

How do you design web pages that are aesthetically and technically intriguing without alienating those in your audience with older browsers? Does a page that is designed to be functional on all browsers necessarily need to be boring? Is it possible to please everyone? And if not, where do you draw the line? How many past versions do you need to cater to with your designs?

This chapter provides background information, statistics, and current wisdom from professional web designers that may help you to make some of these decisions.

There's no absolute rule here. While it's important to make your content accessible to the greatest number of users, experimentation and the real-world implementation of emerging technologies is equally important to keep the medium pushing forward. The key to making appropriate design decisions lies in understanding your audience and considering how your site is going to be used.

The browser market is dominated by the two major browsers: Netscape Navigator and Microsoft Internet Explorer. As of this writing, Navigator is in version 4.0 and Internet Explorer is in version 5.0. Together, the "Big Two," including their collective past versions, account for approximately 90% (or more) of browser use today.

The browser landscape has been dominated by these two contenders as they battle it out for market dominance. Their struggle to be cooler than the next guy has resulted in a collection of proprietary HTML tags as well as incompatible implementations of new technologies (most notoriously Dynamic HTML, but also JavaScript and Cascading Style Sheets). On the positive side, the competition between Netscape and Microsoft has also led to the rapid advancement of the medium as a whole.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The browser market is dominated by the two major browsers: Netscape Navigator and Microsoft Internet Explorer. As of this writing, Navigator is in version 4.0 and Internet Explorer is in version 5.0. Together, the "Big Two," including their collective past versions, account for approximately 90% (or more) of browser use today.

The browser landscape has been dominated by these two contenders as they battle it out for market dominance. Their struggle to be cooler than the next guy has resulted in a collection of proprietary HTML tags as well as incompatible implementations of new technologies (most notoriously Dynamic HTML, but also JavaScript and Cascading Style Sheets). On the positive side, the competition between Netscape and Microsoft has also led to the rapid advancement of the medium as a whole.

Netscape publishes information for developers at http://developer.netscape.com/. Of particular interest are the documentation pages, including listings of Netscape's HTML tag support at http://developer.netscape.com/docs/manuals/.

Microsoft provides a rich resource of developer information at their SiteBuilder Network site, http://www.microsoft.com/sitebuilder/, and the SiteBuilder Workshop, http://www.microsoft.com/workshop/.

Most web authors base their designs on the functionality of Navigator and Internet Explorer, since they claim the lion's share of the market; however, there are a number of other browsers you may choose to take into consideration.

Section 1.1.1.1: Internet Explorer 4.0 on the Macintosh

Not all IE4.0 browsers are created equal! The Macintosh version of IE4.0 lacks significant functionality found in its Windows sibling, so including 4.0-specific features in your site may still leave some users out. As a general guideline, treat Mac IE4.0 like Netscape 3.0.

Some documented shortcomings include:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Faced with the dilemma of varying browser capabilities, web designers have developed a variety of design approaches, some more extreme than others. The "correct" way to handle a particular site, of course, depends on its use and audience, but this section should provide a peek into the different positions in the ongoing debate over where to draw the line.

A minority of web developers adhere to the ideal standards that the Web should be accessible to everyone. They may also maintain that presentation should be in the hands of the end user, not the author. These designers tend to stick with the safest HTML standard (currently HTML 3.2 or even 2.0) and make sure that pages work on all browsers, including Lynx and version 1.0 of the popular browsers.

In web design discussion forums, there is consistently a voice representing the position that all the current embellishments to HTML (Java, JavaScript, style sheets, and DHTML) are unnecessary to successful communication over the Web. Designers who design for the lowest common denominator may choose not to use any of these technologies in their designs.

Another minority, at the other extreme end of the spectrum, are the web developers who design only for the most current version of popular browsers (as of this writing, Navigator 4.0 and Internet Explorer 4.0), with little concern for site performance for other users. The statement "tell them to upgrade—it's free !" has often been used in defense of this design tactic. Beyond this, there are even designers who design for only the most current version of one particular browser. Note that this approach may be perfectly appropriate for intranet design.

This approach has the obvious disadvantage of alienating a large percentage of the audience. If the functionality of a site depends on a specific trick, for example, if you can't get off the front page without JavaScript, then your site has problems communicating.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Whatever your chosen browser, one key to success is to make sure you are writing HTML correctly.

There are a number of online resources that check your web site for various quality issues, including the browser compatibility (or HTML Specification compliance) of your HTML code. There are also HTML validators that check your code for errors.

All will do a certain number of tests for free; however, to get the really good stuff, you generally have to pay for the individual service or a year's subscription for full access to the site. For example, WebSiteGarage provides a nifty (and fee-based) feature called "Browser Snapshot" that will provide up to 18 screenshots of your page on a variety of browsers, including all past versions. This can be a good way to run tests if you don't have access to all of these browsers on your own.

Some of the more popular HTML validation services include:

The World Wide Web Consortium's HTML Validator: http://validator.w3.org/
WebSiteGarage: http://www.websitegarage.com/
NetMechanic: http://www.netmechanic.com/
Doctor HTML: http://www2.imagiware.com/RxHTML/

If these don't suit you, there are a large number of HTML validators listed on Yahoo.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As with most design challenges, making appropriate decisions regarding which browsers to support and which new technologies to adopt largely depends on knowing your audience. Before designing a new site, be sure to spend plenty of time up front researching the likely platforms, browsers, technical savvy, and connection speeds of the users you are targeting. If you are redesigning an existing site, spend time with the server logs to analyze past site usage.

There are no browser-support guidelines that can anticipate every design situation; however, the following scenarios should start you thinking:

If you are designing a scientific or academic site, you should probably pay extra attention to how your site functions in Lynx (or other graphics-free browsing environments).
If your site is aimed at a consumer audience—for instance, a site that sells educational toys to a primarily "mom"-based audience—don't ignore your site's performance and presentation in the AOL browsers.
If you are designing for a controlled environment, such as a corporate intranet, or even better, a web-based kiosk, you've got it made! Knowing exactly what browser and platform your viewers are using means you can take full advantage of the whistles and bells (and even proprietary features) appropriate to that browser. If you are designing a standalone kiosk, you may even have the luxury of loading the fonts you want to use. Just be sure your design won't crash the browser since there's no one there to restart it for you immediately.

In these situations, the "current version design" strategy discussed earlier in this chapter is entirely appropriate (just don't get spoiled)!
If you are designing a computer game site aimed at young gaming geeks, you can probably assume they will have the latest browsers and plug-ins (or will get them if you say they need them).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Another important factor for making web design decisions is knowing how your site is going to be used. Site users tend to fall into two broad categories: those who are on a mission for information, and those who are surfing the Web for entertainment. In general, sites that serve the latter audience have more opportunity to try out cutting-edge or plug-in technologies that improve the overall user experience of the site. For informational sites, you wouldn't want to base the availability of the information on a client-side technology.

Of course, there are plenty of exceptions to this overly generalized rule. For instance, WebMonkey (http://www.webmonkey.com/ ) is an informational site that uses a DHTML-based interface, based on the assumption that its developer audience is using the latest tools. WebMonkey also uses browser detection to serve alternative versions for those without DHTML capabilities. So just because you have a "serious" site doesn't mean you should abandon new technologies entirely.

Another unique case is a site that is about the technology being used, such as a VRML environment. In this situation, you have every right to expect users to use the appropriate browser or plug-in to catch up with your content. (Although, it still might be nice to at least provide some screenshots to show the others what they're missing!)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The final word in the dilemma of designing for a variety of browsers is always TEST! Test your site on as many browsers, browser versions, and platform configurations as you can get your hands on.

Professional web design firms run their sites through a vigorous quality assurance phase before going "live." They generally keep a bank of computers of varying platforms and processing powers that run as many versions of browsers (including Lynx) as possible.

If you do not have the resources to keep a similar set-up on your own, make the site available on a private test site and take a look at it on your friends' computers. You might view it under corporate conditions (a Windows machine with a 4.0 browser, and a T1 connection), then visit a friend at home to see the same site on AOL with a 28.8 modem. (If nothing else, it's a good excuse to get away from your computer and visit your friends!)

Although your pages will certainly look different in different environments, the idea is to make sure that nothing is outright broken and that your content is being communicated clearly.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

One of the most vexing aspects of web design is knowing that your page is at the mercy of the software and hardware configuration of each individual user. A page that looks great on your machine may look radically different, or perhaps even ghastly, when viewed on another user's set-up. This is partly due to the browser's functionality (as discussed in Chapter 1) and the individual user's preferences (font size, colors, etc.), but the display device itself also plays a large part in the success of the page's design.

This chapter looks at the ways in which design decisions are influenced by the wide range of displays and viewing conditions. For the majority of your audience, the variation in display is a function of the monitor's size (or, more accurately, its resolution) and color capabilities. However, it is important to keep in mind that the diversity does not end there. Some users may be watching your web page on TV. Still others may be viewing it in the palm of their hand on a PDA (personal digital assistant) or cell phone. Sight-impaired users may be listening to your page, not viewing it.

Browser windows can be resized to any dimension, limited only by the maximum size of the monitor. Designing for an unknown amount of browser real estate is a challenge unique to web design and one that is particularly troublesome for designers who are accustomed to the printed page.

In discussion forums frequented by web design professionals, no topic is more often addressed (nor hotly debated) than the question of which monitor resolution to design for. As with most web design issues, there is no "right" way to design for the Web, and your decisions should always be guided by your knowledge of your target audience and the purpose of your site. Still, it is helpful to understand the environment and to know how others are maneuvering within it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Browser windows can be resized to any dimension, limited only by the maximum size of the monitor. Designing for an unknown amount of browser real estate is a challenge unique to web design and one that is particularly troublesome for designers who are accustomed to the printed page.

In discussion forums frequented by web design professionals, no topic is more often addressed (nor hotly debated) than the question of which monitor resolution to design for. As with most web design issues, there is no "right" way to design for the Web, and your decisions should always be guided by your knowledge of your target audience and the purpose of your site. Still, it is helpful to understand the environment and to know how others are maneuvering within it.

This section looks at the range of monitor resolutions and presents the current wisdom on making appropriate design decisions. The design advice and "wisdom" presented here has been culled from a number of popular web design mailing lists over the course of nearly half a year.

The first step in determining the likely size of your web page is to look at the maximum amount of space provided by the computer monitor. Computer monitors come in a variety of standard sizes, typically indicated in inches. Some typical monitor sizes are 13", 14", 17", 19", 20", and 21".

The more meaningful measurement, however, is monitor resolution—the total number of pixels available on the screen. The higher the resolution, the more detail can be rendered on the screen. When you know the available number of pixels, you can design your graphics (also measured in pixels) and page elements accordingly. Table 2.1 presents a list of some standard monitor resolutions supported by Macintosh and PC platforms. This is not a complete listing, merely the most commonly occurring configurations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Closely related to the issue of varying monitor resolutions is the question of whether web pages should be designed to be flexible (resizing and adapting to various window sizes) or fixed at a particular size, (giving the designer more control of the page's dimensions) There are very strong opinions on both sides. Naturally, there are good reasons for and against each approach.

You may find that you choose a fixed structure for some sites and allow others to be flexible. You may find that you have strong convictions that one or the other approach is the only way to go. Either way, it is useful to be familiar with the whole picture and the current opinions of professional web designers. This section attempts to present a balanced overview of the possibilities and the pitfalls.

Web pages are flexible by default. The text and elements in a straightforward HTML file will flow into the browser window, filling all available space, regardless of the monitor size. When the browser window is resized, the elements reflow to adapt to the new dimensions. This is the inherent nature of the Web. Designers who are initially traumatized by the unpredictability of where the page elements land usually just learn to let go of some control over the page.

Many designers make a conscious decision to construct pages so they can withstand stretching and shrinking web windows. This approach comes with advantages and disadvantages.

Section 2.2.1.1: Advantages

The reality is that web pages will be displayed on a variety of monitor resolutions and conditions; keeping the page flexible allows it to be "customized" for every display.
The whole monitor space is filled, without the potentially awkward empty space left over by many fixed-width designs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Responsible web design includes making pages accessible even to users with disabilities, such as hearing or sight impairments. The World Wide Web Consortium (W3C) has launched its Web Accessibility Initiative (WAI), which aims to make the Web more universally accessible. The WAI develops technologies, HTML authoring guidelines and tools, and also promotes education and research. The success of the initiative, however, relies on the participation of web developers to build sites according to the proposed guidelines.

Sight-impaired users may simply use a device that magnifies the screen for easier reading, in which case there are no special design requirements. Many vision-impaired users use a text browser (such as Lynx) in conjunction with software that reads the contents of the screen aloud. Some use devices that translate the text into Braille. Either way, there is a greater reliance on the structure and the text within the document. Content in graphics may be completely lost.

The following list presents a few simple measures you can take to make your pages more accessible.

Provide alternative text for all images (via the <img> tag's alt attribute). Make the alternative text rich and meaningful. Adding alt text should be standard procedure for all web page creation; in fact, in the new HTML 4.0 specification, the alt attribute is now a required part of the <img> tag. (See Chapter 9,.for more information.)
Add periods at the end of alt text so a speech device can locate the logical end of the phrase.
When linking a graphic, provide a caption under it that also serves as a text link.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Web isn't just for personal computers anymore! Web browsers are increasingly making their way into our living rooms, briefcases, and cars, in the form of WebTV, handheld PDA devices, and even cellular phones. These extra-small displays introduce new design concerns.

WebTV, a device that turns an ordinary television and phone line into a web browser, hit the market in 1996 and is experiencing a slow but steady growth in market share. As of this writing, it is barely a blip on the radar screen of overall browser usage, but because numbers are increasing some developers are taking its special requirements into consideration. Some sites are being developed specifically for WebTV.

WebTV uses a television rather than a monitor as a display device. The live space in the WebTV browser is a scant 544×378 pixels. The browser permits vertical paging down, but not horizontal scrolling, so wider graphics will be partially obscured and inaccessible. Principles for designing legible television graphics apply, such as the use of light text on dark backgrounds rather than vice versa and the avoidance of any elements less than 2 pixels in width.

WebTV publishes a site with guidelines for web developers called Primetime. For more detailed information on the special requirements of WebTV, visit http://www.webtv.net/primetime/.

The increased popularity and usefulness of the Web combined with the growing reliance on hand-held communications devices such as palm-top computers, PDAs, and cellular telephones has resulted in Web browsers squeezing into the coziest of spaces.

Many of these devices use thin client browsers for web content display. A thin client is one that runs with minimal processing requirements on the client side, leaving the bulk of the work to be done by the server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you are accustomed to designing for print, the Web introduces a number of new concepts and new ways of doing things. Part of what makes web design unique is that the pages are displayed on a computer monitor, not paper, requiring familiarity with new color models. In addition, you need to work within the unique environment of the web browser. The HTML markup language brings its own limitations to the mix.

This chapter discusses some basic web design concepts, which may be new for print designers or for anyone who is just getting started in web design. It provides necessary background information about the web environment, including how the browsers deal with color, graphics, and typography, so that you can make design decisions that are appropriate to the medium.

The Web requires designers to think about color in new ways. In part, it means understanding color in a more technical manner—the appearance of a page can benefit greatly if a designer knows what's going on "under the hood." The peculiarities of working with color in web design are functions of the following simple principles:

Monitors. Web pages are displayed on computer monitors, therefore the basic rules of how computers and monitors handle color apply to web pages as well.
Browsers. Because browsers have built-in resources for rendering color when running on systems with limited color display capacity, they can alter the appearance of the colors in your pages.
HTML. Colors on a web page that are not part of a graphic (for example, background and text colors) need to be properly identified in the HTML tags of the document. Specifying color in HTML is covered in Chapter 5.

Color on monitors is made of light, so traditional systems for specifying color for print (CMYK, Pantone swatches, etc.) do not apply.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Web requires designers to think about color in new ways. In part, it means understanding color in a more technical manner—the appearance of a page can benefit greatly if a designer knows what's going on "under the hood." The peculiarities of working with color in web design are functions of the following simple principles:

Monitors. Web pages are displayed on computer monitors, therefore the basic rules of how computers and monitors handle color apply to web pages as well.
Browsers. Because browsers have built-in resources for rendering color when running on systems with limited color display capacity, they can alter the appearance of the colors in your pages.
HTML. Colors on a web page that are not part of a graphic (for example, background and text colors) need to be properly identified in the HTML tags of the document. Specifying color in HTML is covered in Chapter 5.

Color on monitors is made of light, so traditional systems for specifying color for print (CMYK, Pantone swatches, etc.) do not apply.

Section 3.1.1.1: RGB color

Computer monitors display colors by combining red, green, and blue light. This color system is known as RGB color.

RGB color is a 24-bit system, with eight bits of data devoted to each of three color channels. Eight bits of data can describe 256 colors. With 256 possible colors in each of the three channels, the total possible number of colors is calculated by multiplying 256×256×256 for a total of 16,777,216. That's more than enough colors to provide stunning representations of artwork and photography.

The problem is that only a small percentage of computers in the world are equipped to display 24-bit color. Many, many more support only 8-bit color; these systems can display only 256 colors at any one time. The good news is that, by using a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Print designers will need to adapt their graphics production skills for the Web to take into account the peculiarities of graphics that are distributed over a network and displayed on computer monitors.

As of this writing, nearly all of the graphics that you see on the Web are in one of two formats: GIF and JPEG. A third worthy contender, the PNG file, is struggling for browser support and attention. What follows is a very brief introduction to the "big three" of online graphic formats. More detailed descriptions are provided in the chapters dedicated to each format.

Section 3.2.1.1: The ubiquitous GIF

The GIF (Graphic Interchange Format) file format is the traditional darling of the Web. It was the first file format to be supported by web browsers and it continues to be the format for the vast majority of graphics on the Web today.

GIFs are indexed color files with a maximum 8-bit palette capacity, which means that a GIF can contain a maximum of 256 pixel colors. Because they compress color information by rows of pixels, GIF files are most appropriate for graphics that contain areas of flat color.

See.Chapter 14 , for complete information on the GIF file format.

Section 3.2.1.2: The handy JPEG

The second most popular graphics format on the Web today is the JPEG ( Joint Photographic Experts Group) format. JPEGs contain 24-bit color information—that's millions of colors, as opposed to GIF's 256. They use what is called a "lossy" compression scheme, which means that some image information is thrown out in the compression process, but in most cases, the degradation of the image is not detrimental or even noticeable.

Photographic images, or any image with subtle gradations of color, are best saved as JPEG files because they offer better image quality packed into a smaller file. JPEGs, however, are not a good solution for flat, graphical images because they tend to mottle colors and the resulting file will generally be a lot larger than the same image saved as a GIF.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

HTML was created with the intent of putting the ultimate control of presentation in the hands of the end-user. This principle makes its most resounding impact when it comes to typography. The stark fact of web design as we know it today is that there is no way of knowing exactly how your text is going to look. Take a look at your browser's preferences and you will find that you (and every other surfer) are able to specify the fonts and sizes that you prefer for online viewing.

For anyone accustomed to designing for other media, this loss of font control is cause for major frustration. From the time they discovered the Web, designers (and their corporate clients) have been pushing for ways to control typography in order to produce attractive and predictable web sites.

Great strides have been made in this effort since the early days of the Web and HTML 1.0; however, as of this writing, the font issue is still unfolding. This section discusses possible strategies and technologies (along with their advantages and disadvantages) for designing type in web documents. It also addresses the issue of using foreign (non-western) characters on web pages.

About the only thing you can be sure of when you're designing web pages with basic HTML is that you have two fonts to work with: a proportional font, and a fixed-width font. The problem is that you don't know specifically which ones or at what size they will be displayed.

Section 3.3.1.1: Proportional font

A proportional font (called "Variable Width Font" in Netscape Navigator) is one that allots different amounts of space to each character, based on its design. For instance, in a proportional font, a capital "W" takes up more horizontal space on the line than a lowercase "i." Times, Helvetica, and Arial are examples of proportional fonts.

Web browsers use a proportional font for the majority of text in the web page, including body text, headings, lists, blockquotes, etc. In general, proportional fonts are easier to read for large bodies of text.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Even if you focus primarily on what's commonly referred to as "front-end" web development—HTML documents and web graphics—the server and the way it is configured may impact the way you work. In most cases, there is no way to avoid making first-hand contact with the server, even if it's just to upload files.

For this reason, all web designers should have a basic level of familiarity with servers and what they do. At the very least, this will enable you to communicate more clearly with your server administrator. If you have permission for greater access to the server, it could mean taking care of certain tasks yourself without needing to wait for assistance.

This chapter provides an introduction to server terminology and functions, basic Unix commands, and file (MIME) types. It also discusses uploading files and setting permissions, which designers often need to do.

A server is any computer running software that enables it to answer requests for documents and other data. The programs that request and display the documents (such as a browser) are called clients . The terms "server-side" and "client-side," in regard to specific functions like imagemaps, refer to which machine is doing the processing. Client-side functions happen on the user's machine; server-side functions occur on the remote machine.

Web servers answer requests from browsers (the client program), retrieve the specified file (or execute a CGI script) and return the document or script results. Web browsers and servers communicate via the Hypertext Transfer Protocol (HTTP).

As of this writing, the majority of web servers are running on the Unix platform. This is why a lot of Unix terminology is still used in the web world. You may even need to learn a few Unix commands in the course of a job. However, the percentage of Windows NT, Windows 95, and even Macintosh servers is steadily increasing. Some server packages offer a graphical interface as an alternative to Unix command-line controls.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

A server is any computer running software that enables it to answer requests for documents and other data. The programs that request and display the documents (such as a browser) are called clients . The terms "server-side" and "client-side," in regard to specific functions like imagemaps, refer to which machine is doing the processing. Client-side functions happen on the user's machine; server-side functions occur on the remote machine.

Web servers answer requests from browsers (the client program), retrieve the specified file (or execute a CGI script) and return the document or script results. Web browsers and servers communicate via the Hypertext Transfer Protocol (HTTP).

As of this writing, the majority of web servers are running on the Unix platform. This is why a lot of Unix terminology is still used in the web world. You may even need to learn a few Unix commands in the course of a job. However, the percentage of Windows NT, Windows 95, and even Macintosh servers is steadily increasing. Some server packages offer a graphical interface as an alternative to Unix command-line controls.

Some popular servers include:

NCSA Server: This is publicly available server software maintained by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. It runs on the Unix platform.
Apache: A variation of NCSA, Apache has become the most popular web server due to the fact that it is a powerful server and it is available for free. It runs primarily on Unix, but is being released to run on other platforms, including Windows NT.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you work with the Web long enough, chances are you'll run into the need to communicate with a Unix machine. On Macs and PCs, most functions can be performed using tools with graphical interfaces; however, at times there is no substitute for a good old-fashioned telnet session. Besides, a little Unix never hurt anyone.

Telnet is a "terminal emulation" protocol that allows you to log in to other computer systems on a network (such as the Internet). It also refers to any application used for communicating with the telnet protocol. A telnet program will give you a character-based terminal window on another system from which you can enter simple command-line instructions. Figure 4.1 shows a typical telnet session.

Figure 4.1: Typical telnet session

This section provides a very brief introduction to basic terminology and commands that will enable you to manipulate files and directories on a Unix machine. If you are interested in learning more, read Learning the Unix Operating System and Unix in a Nutshell, both published by O'Reilly & Associates, Inc.

When you open a connection to a remote server with your telnet program, the first thing you see is a prompt to log in to the system. Before you can access the server, the system administrator has to set up a Unix account for you. You will be given a name and password you can enter at the login: and password: prompts respectively.

When you log in successfully, you will get a Unix system prompt, either a $ or a % (or sometimes #) depending on the flavor of Unix the server is running, which tells you that the system is "ready." At this point, you are using a program called the shell, which interprets the commands you type and invokes the programs you ask for. You will automatically be placed in your home directory.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In order for your files to traverse the network successfully, you must name them in accordance with established file naming conventions.

Avoid character spaces in filenames. Although this is perfectly acceptable for local files on a Macintosh or Windows 95/98/NT machine, character spaces are not recognized by other systems.
Avoid special characters such as ?, %, #, etc. in filenames. It is best to limit filenames to letters, numbers, underscores (in place of character spaces), hyphens, and periods.
Use proper suffixes. HTML documents require the suffix .html (or .htm if on a Windows server). GIF graphic files take the suffix .gif, and JPEGs should be named .jpg or .jpeg. If your files do not have the correct suffix, the browser will not recognize them as web-based files. Suffixes for a large number of common file types are listed later in this chapter.
Filenames are case-sensitive in HTML. Consistently using all lowercase letters in filenames, while certainly not necessary, may make them easier to remember.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The most common transaction a web designer will have with a web server is the uploading of HTML documents, graphics, and other media files. Files are transferred between computers over a network via a method called FTP (File Transfer Protocol).

If you are working in a telnet session on Unix, you can run the ftp program and transfer files with a hefty collection of command-line arguments (not covered in this book).

Fortunately, if you work on a Mac or PC, there are a number of FTP programs with graphical interfaces that spare you the experience of transferring files using Unix command lines. In fact, FTP functions are now built right into most WYSIWYG HTML editors, such as GoLive Cyberstudio, Claris HomePage, and Dreamweaver, among others. On the Mac, dedicated programs that allow "drag-and-drop" file transfer such as Fetch and Anarchie are quite popular. On the PC, there are numerous simple FTP programs, such as WS_FTP and AceFTP. These (and many others) are available for download at http://www.shareware.com/ (search for "ftp").

The Netscape Navigator and Internet Explorer browsers also function as simple FTP clients, offering the ability to both download and upload files with a drag-and-drop interface.

Regardless of the tool you use, the basic principles and processes are the same. Before you begin, you must have an account with permission to upload files to the server. Check with the server administrator to be sure this is set up. (Note: you don't necessarily need an account to upload and download files if the server is set up as an anonymous ftp site.)

Launch the FTP program of your choice and open a connection with your server. You'll need to enter the exact name of the server, your account name, and password.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Servers add a header to each document that tells the browser the type of file it is sending. The browser determines how to handle the file based on that information—whether to display the contents in the window, or to launch the appropriate plug-in or helper application.

The system for communicating media types closely resembles MIME (Multipurpose Internet Mail Extension), which was originally developed for sending attachments in email. The server needs to be configured to recognize each MIME type in order to successfully communicate the media type to the browser.

If you want to deliver media beyond the standard HTML files and graphics (such as a Shockwave Flash movie or an audio file), you should contact your server administrator to be sure the server is configured to support that MIME type. Most common formats are built in to current versions of server software, but if it isn't there already, the administrator can easily set it up if you provide the necessary information.

The exact syntax for configuring MIME types varies among server software; however, they all require the same basic information: type, subtype, and extension. Types are the most broad categories for files. They include text, image, audio, video, application, etc. Within each category are a number of subtypes. For instance, the file type image includes the subtypes gif, jpeg, etc. The extension refers to the file's suffix, which the server uses to determine the file type and subtype. Not all extensions are standardized.

Table 4.3 lists common media types by extension along with their MIME type/subtype information. The ASCII/Binary information is provided to aid in making upload decisions.

Of course, new technologies and file types are emerging every day, so keep in mind that it is the web designer's responsibility to make sure that for any new media type the appropriate information is communicated to the server administrator.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

HTML (Hypertext Markup Language) is the language used to create web documents. It defines the syntax and placement of special instructions (tags) that aren't displayed, but tell the browser how to display the document's contents. It is also used to create links to other documents, either locally or over a network such as the Internet.

The HTML standard and all other Web-related standards are developed under the authority of the World Wide Web Consortium (W3C). Standards, specifications, and drafts of new proposals can be found at http://www.w3.org. The most recent work is the HTML 4.0 Specification, which is growing in support by major browsers.

In practice, the HTML "standard" is influenced heavily by the tags that are introduced and supported by the popular browsers, i.e., Microsoft Internet Explorer and Netscape Navigator. These tags may or may not be part of the current HTML specification at any given time.

This chapter provides a basic introduction to the background and general syntax of HTML, including document structure, tags, and their attributes. It also looks briefly at good HTML style and the pros and cons of using WYSIWYG authoring tools.

For a more in-depth study of HTML, I recommend HTML: The Definitive Guide, Third Edition, by Chuck Musciano and Bill Kennedy (O'Reilly & Associates, 1998) Another excellent resource for HTML tag information is the HTML Compendium (created by Ron Woodall). The Compendium provides an alphabetical listing of every HTML tag and its attributes, with explanations and up-to-date browser support information for each. The browser support charts accompanying each tag in this book are based on their work. The HTML Compendium can be found at http://www.htmlcompendium.org.

HTML documents are simple ASCII text files, which means you can use any minimal text editor to write them. Fortunately, there are editing tools designed especially for writing HTML. These save time by providing shortcuts for repetitive tasks like setting up documents, tables, or simply applying styles to text. HTML editors are not the same as WYSIWYG authoring tools (discussed next)—you need to know how to compose HTML by hand; editors just make the process faster and easier.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

HTML documents are simple ASCII text files, which means you can use any minimal text editor to write them. Fortunately, there are editing tools designed especially for writing HTML. These save time by providing shortcuts for repetitive tasks like setting up documents, tables, or simply applying styles to text. HTML editors are not the same as WYSIWYG authoring tools (discussed next)—you need to know how to compose HTML by hand; editors just make the process faster and easier.

There are scores of simple HTML editors available, and many of them are free. Just enter "HTML Editor" in the search field of Shareware.com (http://www.shareware.com.) and wade through the results. For purposes of brevity, I'm going to cut to the chase.

Windows users should definitely check out HomeSite, a high-powered and inexpensive HTML editor from Allaire Corporation. It, too, has HTML shortcuts and templates, color-coded HTML syntax, an FTP function, spell-checker, HTML syntax checker, and multi-file search-and-replace. In addition, it includes wizards for creating more complex elements (such as frames, JavaScript, and DHTML) and many other attractive features. For more information and to download a demo copy, see http://www.allaire.com.

If you're working on a Macintosh, you want BBEdit, a commercial HTML editor from Bare Bones Software, Inc. It is overwhelmingly the editor of choice among Mac-based web developers. It includes features such as an array of HTML shortcut tools, color-coded HTML syntax, multiple-file search and replace, a built-in FTP function, support for 13 programming languages, a table builder, an HTML syntax checker, and a lot more. For more information and to download a demo, see http://www.bbedit.com.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The last two years have seen an explosion in the web authoring tool market. WYSIWYG (what-you-see-is-what-you-get) HTML editors have graphical interfaces that make writing HTML more like using a word processing or page layout program. In the beginning, their goal was to spare authors from ever having to touch an HTML tag in the way that page layout programs protect designers from typing out PostScript. Today, their role has shifted towards making document production more efficient and automated while still providing access to the HTML source.

These days, nobody pretends that WYSIWYG authoring tools will excuse you from learning HTML completely, but they do provide a considerable head start for many menial tasks. Because these tools are notorious for adding extra code to HTML files, the question of whether or not to use them for web production has become something of a holy war among web developers.

HTML purists insist that hand-writing HTML in a no-frills text editor is the only way to do it "right," and that the HTML documents made by WYSIWYG tools are of unacceptable quality. On the other hand, many developers appreciate being spared the grunt-work of typing every HTML tag and find the WYSIWYG environment useful for viewing the page and making design decisions on the fly.

Of course, there are many reasons both for and against using these tools. The controversy should lessen as the tools, which are currently in their infancy, work out their kinks and start producing clean and robust code. If you do use a WYSIWYG tool, expect to do some manual fine-tuning to the resulting HTML code.

Section 5.2.1.1: Pros

They are good for beginners. They can even be useful for teaching HTML because you can lay out the page the way you want, then view the resulting HTML.
They are good for quick prototyping. Design ideas can be tried out on the fly.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

An HTML document contains text (the contents of the page) with embedded tags, which provide instructions for the structure, appearance, and function of the contents.

An HTML document is divided into two major portions: the head and the body. The head contains information about the document, such as its title and "meta" information describing the contents. The body contains the actual contents of the document (the part that is displayed in the browser window).

The following example shows the tags that make up the standard skeletal structure of an HTML document:

<HTML>
<HEAD>      
<TITLE>Document Title</TITLE>      
</HEAD>
<BODY>      
Contents of Document      
</BODY>
</HTML>

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Every HTML tag is made up of a tag name, sometimes followed by an optional list of attributes, all of which appears between angle brackets < >. Nothing within the brackets will be displayed in the browser. The tag name is generally an abbreviation of the tag's function (this makes them fairly simple to learn). Attributes are properties that extend or refine the tag's function.

The name and attributes within a tag are not case sensitive. <BODY BGCOLOR=white> will work the same as <body bgcolor=white>. However, values for particular attributes may be case sensitive, particularly URLs and filenames.

Most HTML tags are containers, meaning they have a beginning (also called "opener" or "start") tag and an end tag. The text enclosed within the tags will follow the tag's instructions, as in the following example:

The weather is <I>gorgeous</I> today.

Result: The weather is gorgeous today.

An end tag contains the same name as the start tag, but it is preceded by a slash ( / ). You can think of it as an "off " switch for the tag. End tags never contain attributes.

For some tags, the end tag is optional and the browser determines when the tag ends by context. This practice is most common with the  (paragraph) tag. Browsers have supported the  tag without its end tag, so many web authors take advantage of the shortcut. Not all tags allow this, however, and not all browsers are forgiving, so when in doubt include the end tag. This is especially important when using Cascading Style Sheets (discussed in Chapter 23) with your document.

In the HTML charts that appear in this book, container tags are indicated with the syntax < >...</>. If the end tag is optional, it will be so noted in the tag's explanation.

A few tags do not have end tags because they are used to place standalone elements on the page. The image tag (<img>) is such a tag and it simply plops a graphic into the flow of the page. Other standalone tags include the linebreak (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Some information in an HTML document, including certain tags, will be ignored when the document is viewed in a browser. These include:

Line breaks

Line returns in the HTML document are ignored. Text and elements will wrap continuously until they encounter a  or   tag within the flow of the document text. Line breaks are displayed, however, when text is tagged as preformatted text (<pre>).

Tabs and multiple spaces

When a browser encounters a tab or more than one consecutive blank character space in an HTML document, it will display it as a single space. So, if the document contains:

far,            far                away

the browser will display:

far, far away

Extra spaces can be added within the flow of text by using the nonbreaking spacecharacter entity ( ). Multiple spaces will be displayed, however, when text is tagged as preformatted text (<pre>).

Multiple tags

A series of  (paragraph) tags with no intervening text is interpreted as redundant by all browsers and will display as though it were only a single  tag. Most browsers will display multiple   tags as multiple line breaks.

Unrecognized tags

A browser simply ignores any tag it doesn't understand or that was incorrectly specified. Depending on the tag and the browser, this can have varied results. Either the browser will display nothing at all, or it may display the contents of the tag as though it were normal text.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

This section offers some guidelines for writing "good" HTML—code that will be supported by a wide variety of browsers, that will be easily handled by applications expecting correct HTML, and that will be extensible to emerging technologies built on the current HTML specification.

Follow HTML syntax as described by the current available W3C specification: Writing HTML "correctly" may take extra effort, but it ensures that your

Table of Contents

Section 1.1.1.1: Internet Explorer 4.0 on the Macintosh

Section 2.2.1.1: Advantages

Section 3.1.1.1: RGB color

Section 3.2.1.1: The ubiquitous GIF

Section 3.2.1.2: The handy JPEG

Section 3.3.1.1: Proportional font

Section 5.2.1.1: Pros